[Sahana_proj] Re: Conflicts with Sahana coding guidelines

Ralph Morelli ram at cs.trincoll.edu
Wed Apr 25 15:08:59 EDT 2007


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?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.trincoll.edu/pipermail/sahana_proj/attachments/20070425/c222d53c/attachment.htm


More information about the Sahana_proj mailing list