[Sahana_proj] Re: Conflicts with Sahana coding guidelines

[Bach Dao]

Hi all, 

 

Changing the header image is not difficult to do. I did this for WeSahana to
change the logo in the top. It involved changing the image in the theme. So
you can look at the theme folder, copy one of the theme and change the
header image to sth you want. The theme can be set to your new theme by
editing the conf file in Sahana. I do not remember the details but that was
the general approach. Hope it helps.

 

From: sahana_proj-bounces at lists.trincoll.edu
[mailto:sahana_proj-bounces at lists.trincoll.edu] On Behalf Of Ralph Morelli
Sent: Wednesday, April 25, 2007 3:09 PM
To: Marmon, Glenn D.
Cc: Trinity Sahana Project Internal Group Mailing list
Subject: [Sahana_proj] 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?

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.trincoll.edu/pipermail/sahana_proj/attachments/20070425/1acb053a/attachment-0001.html