<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">Hi Glenn,<DIV><BR class="khtml-block-placeholder"></DIV><DIV>I'm going to copy this to the list because I think it raises a good general issue.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><BLOCKQUOTE type="cite">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?</BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>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.<DIV><BR class="khtml-block-placeholder"></DIV><DIV>Perhaps someone can suggest an example of this??<BR><DIV><BR class="khtml-block-placeholder"></DIV><DIV>-- ram<BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV>Ralph Morelli <<A href="mailto:ralph.morelli@trincoll.edu">ralph.morelli@trincoll.edu</A>></DIV><DIV>Professor of Computer Science</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR><DIV><DIV>On Apr 25, 2007, at 12:37 PM, Marmon, Glenn D. wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">"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."</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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): <A href="http://oak.conncoll.edu/~gmarmon/erm_calendar.jpg">http://oak.conncoll.edu/~gmarmon/erm_calendar.jpg</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">"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."</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">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?</DIV> </BLOCKQUOTE></DIV><BR></DIV></DIV></BODY></HTML>