[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Template storage mechanism?

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.


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 ;-)


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
Ledger-smb-devel mailing list