[Sahana_proj] RE: Conflicts with Sahana coding guidelines

[Marmon, Glenn D.]

Can anyone out there give ideas on a plan of attack for stripping down Sahana such that it can be used as just the framework and libraries with none of the original modules? You can simply remove the modules after install, but I'd like to be able to install the framework without ever having extranious modules. Simply deleting all the modules from the /mod/ directory understandably causes the Sahana installer to error, so I see two choices in terms of getting this to work - 

1.) Edit the Sahana installer itself - strip it of all the aspects we don't need for our project. This would fit with our plan of stripping down Sahana in general, it just appears to me be somewhat of a daunting task when I look at the contents of the /inst/ folder.
2.) Create our own installer, say "install.php", that performs only the install functions we need (database table creation, etc).

I'm leaning towards #2, but I wanted to see if anyone out on the listserve had any thoughts on what might be the best way for us to do what we want.

Also, does anyone know of a project where such a Sahana strip-down has been successfully done? That might give us an answer as well.

Thanks,
-Glenn


-----Original Message-----
From: Ralph Morelli [mailto:ram at cs.trincoll.edu]
Sent: Wed 4/25/2007 3:08 PM
To: Marmon, Glenn D.
Cc: Trinity Sahana Project Internal Group Mailing list
Subject: Re: Conflicts with Sahana coding guidelines
 
Hi Glenn,

I'm going to copy this to the list because I think it raises a good  
general issue.

Your module looks very nice and you've done a good job of integrating  
it visually within the Sahana look-and-feel. But you're right that  
your application really isn't about disaster recovery.

> Does that sound like a more sensible thing to do - have it be a  
> standalone product that inherits the Sahana framework as opposed to  
> trying to make it a module for the complete Sahana software?

Yes. That's what I would suggest. You would strip Sahana to just  
those modules you want to include---sort of like what we did for the  
HelloWorld module at the beginning of the course.  This is an  
appropriate use of the Sahana (LAMP) framework.  In fact, if you did  
that, it would be useful for us to show to local non-profits as a way  
that Sahana/LAMP could be customized to meet their IT needs.  So, in  
addition to stripping out extraneous Sahana modules, you'll probably  
want to use a different Header and Image and other customizations.  
That's not difficult to do--post questions on the list serve for some  
ideas.   You'll also want to acknowledge Sahana with some kind of  
link, at the bottom of your main page that says "Powered by Sahana".   
This to is not difficult to do.

Perhaps someone can suggest an example of this??

-- ram
Ralph Morelli <ralph.morelli at trincoll.edu>
Professor of Computer Science



On Apr 25, 2007, at 12:37 PM, Marmon, Glenn D. wrote:

> "If I understand your question, you're asking about the code  
> itself, not the look-and-feel of the calendar, which (I'm assuming)  
> uses the Sahana CSS tags and so looks like any other Sahana page."
>
> The calendar code uses its own CSS files and tags - not Sahana's.  
> The calls to the stylesheet are done in a php file seperate from  
> the calendar.inc that is linked to in our Sahana Module Menu.  
> The .inc file creates an iframe, with a source file of  
> v_calendar.php, which is the visual calendar code that uses the  
> Raccuglia Calendar Software stylesheets and CSS tags. We have taken  
> special care not to mix the two. (And we can't, really, the visual  
> breaks if you try to include the code from v_calendar.php directly  
> into calendar.inc) The end result of this system is a page that  
> looks like this (a screenshot from a recent build of the ERM on my  
> local machine): http://oak.conncoll.edu/~gmarmon/erm_calendar.jpg
>
> "I think the answer to this is "it depends on the details". If  
> there are minor differences in the coding guidelines, such that the  
> module's functionality does not become problematic as new releases  
> of Sahana are made, then that should not be a problem. On the other  
> hand, if the differences are great enough that functionality or  
> compatibility become issues, then it should probably be revised.  
> These are the kinds of questions/decisions that would be made by  
> the core team when they review your code."
>
> And this ultimately leads me to a rather large question - does our  
> "module" really belong in the larger Sahana project? I have always  
> wanted to build this project as a Sahana module in terms of  
> framework and style - I love the way Sahana is set up and the way  
> it looks. (That, and at this point, we have a lot of code that  
> isn't worth much if removed from the Sahana framework) The more I  
> think about it, though, the more I doubt whether or not our project  
> truly deals with disaster management. It is used for regular, day  
> to day organization of Response Teams - it is not specialized to do  
> so specifically for disasters. In fact, in case of a disaster, the  
> needs of such an organization may overwhelm our system. So,  
> ultimately, I don't know if the concept of our "module" belongs in  
> the larger Sahana project, whether or not it follows the coding  
> guidelines. Right now, we still plan to develop the ERM as a Sahana  
> Module in terms of framework, but I'm not sure what we want to do  
> about release. I suppose ideally we could release it with a  
> "stripped down" version of Sahana, ie, release the ERM with the  
> Sahana framework but with none of the modules of the regular  
> Sahana. (I'm not quite sure how to go about that, but I'll post  
> questions about that on the listserve when I have them, as I'm sure  
> that'd be the best place for information on that) Does that sound  
> like a more sensible thing to do - have it be a standalone product  
> that inherits the Sahana framework as opposed to trying to make it  
> a module for the complete Sahana software?