Re: Template storage mechanism?

[Les Richardson <..hidden..>]

Hi Chris,

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.
>
> http://www.template-toolkit.org/

Yes, this would be fine. It simplifies the use of templates, not their 
management.

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) 
will work.

We agree to disagree... (grin)

Thanks for the insights.


Les



> Cheers,
>
> Chris
>
> -------------------------------------------------------------------------
> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel