[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Template storage mechanism?
- Subject: Re: Template storage mechanism?
- From: Les Richardson <..hidden..>
- Date: Sat, 7 Apr 2007 13:34:47 -0600 (CST)
On Sat, 7 Apr 2007, Christopher Murtagh wrote:
On 4/7/07, Les Richardson <..hidden..> wrote:
Those are the existing templates, which IMO aren't worth putting on
the filesystem or in the db. I'm really hoping that once we start
doing things properly, we will have a real template engine that will
have a validation mechanism.
What's a template engine?
Software that lets you abstract/automate/generate/manage templates.
There are a number of different approaces and techniques.
TemplateToolkit is a popular one in the Perl world, but I'm not very
familiar with it. I think the plan is to start using this in LSMB.
Yes, this would be fine. It simplifies the use of templates, not their
I chose not to use this, since I've added metadata to the forms generated
from the html templates. This allows me to store defaults, entry type
types (ie. selects, input, checkboxes, textarea), etc. directly in another
metadata table that users can then configure. It adds more configurability
to my app (Open Admin) without having to mess with the templates (for
which I don't have any web based tools yet).
However, filesystems are highly optimized storage spaces. And templates
are complex relatively non-structured data.
xhtml and xml are both structured documents and can be parsed very
well by fairly mature parsing/validation engines.
This was the technique we used for the CMS for www.mcgill.ca (I was
the lead developer of that for aout 6 years), and it worked quite
well. In the last incantation, all use edited content as well as
documents and images were stored in the database. This greatly
simplified replication, as we had 5 machines running www.mcgill.ca
behind a load balancer, begin fed by a single data backend. The
frontend machines would cache data to the filesystem, and respond to
destroy comands when the cache expired (usually because an editor
modified the content). In this scenario, the db backend would
eventually be the bottlneck, but then it could also be replicated with
Slony or some other mechanism.
Yes, this would also work fine. Our differences here are simply one of
philosophy. Both approaches (files in filesystems vs fields in database)
We agree to disagree... (grin)
Thanks for the insights.
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