Hi Mads, Yes, you're right. It's a mix depending on your needs.
Templates simply store 'layout' information, not the data itself. The data itself of course is in the database. Defaults can be stored in configuration files and/or db tables. In OpenAdmin, the configuration files are controlled by the system administrator and he/she sets things like the attendance reasons, etc. The defaults and required fields for data such as student demographics and staff information are stored in a metadata table, which is managed by the school administrators. So the reasons may also be from a access control prespective. Les On Sat, 7 Apr 2007, Mads Kiilerich wrote: > Christopher Murtagh wrote, On 04/07/2007 09:42 PM: >>> Yes, this would also work fine. Our differences here are simply one of >>> philosophy. Both approaches (files in filesystems vs fields in database) >>> will work. >>> >>> We agree to disagree... (grin) >>> >> >> Agreed... or is that disagreed? :-) >> >> After having worked on large systems like this, I prefer to keep code >> and user content in their own places. From my experience, it makes for >> easier maintenance and backups. >> > > My 5 cents of experience from systems like this is that it isn't black > and white. > > Default values "are" a kind of code. When systems are upgraded then > default values in use could/should be upgraded as well. The file system > is a natural place for these. > > Customizations made through the web are obviously user content and > should be stored in the database. The (implicit) choice to use the > default values could be considered "user content" as well (or at least > some kind of data that could be stored in the database). > > (And some users will in some cases prefer to make customizations in the > file system, even though the customized files are data really belongs in > the database...) > > I have found that the best compromise is to first search for data (e.g. > templates) in the database and then - if not found - fall back to the > file system. Perhaps with a number of "layers" both places. > > (Another interesting approach could be to propagate changes to "the > other place" whenever something changes. But that could easily end up > with collisions where both versions has been changed and can't propagate > without loosing data...) > >> there's more than one way to do it - that's the perl motto after all. >> > > - but there might be more than one way anyway ;-) > > /Mads > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Ledger-smb-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
