On Tue, 1 Aug 2000, Bill Moseley wrote:
> In additions to a comparison of features, people (including me) might find
> it useful to have a general overview and comparison of the different
> templating _technologies_ and what type of applications work well with each
> and why.
I was planning to help out with writing just such an essay. It needs to
explain things like callback vs. pipeline, and why you might want one or
the other for certain apps.
> In my mind, almost all my applications seem to fit a system where a my
> application uses the templates, instead of the templates using my
> application. In other words, URLs map to the application and not to
> pages. I assume the likes of TT and HTML::Template fit this, but
> Embperl, Mason, and ASP are more based on URLs mapping to templates.
Yes, the first is pipeline, and the second is callbacks (in my
terminology anyway).
> Now, I think I have rather simple needs. I'm not sure which current system
> best fits. The tricky part for me is when used with co-branding. Any
> suggestions?
TT, Mason, and HTML::Template would all work, and others probably would
too but I'm not as familiar with how they handle template search paths.
> - Shared template cache across server children
That's pretty hard for any system that compiles templates to perl subs,
which most of the fastest ones do. You can't share compiled perl subs
across children except by loading them before the fork.
> plus some smart way to detect changed templates without doing a stat()
> on every request (which is what I'm currently doing -- and since my
> templates are full of INCLUDEd other templates, that's a bunch of
> stats).
I wonder if people make too much of the file stat cost. Well, Mason
handles this in a reasonably efficient way and I think the others just let
you turn it on or off at most, but even with Mason if you want it to do
the right thing you'll have to code some stuff on your end to let it know
your templates have changed (or manually touch a file).
(Hmmm... that might be a cool feature to add to TT in the
Template::Provider class.)
> Say all the templates are stored in the "templates" directory.
> Subdirectories in the "templates" directory contain the templates for
> each of the co-branded sites. When running as co-branded the template
> mapper first looks in the co-branded subdirectory for the template,
> then if not found there, looks in the top level templates directory
> for a template of the same name. More helpful in my case, the same
> process works for templates included within templates so that many of
> the templates (and included templates) are shared. I guess that's
> someone like the "components" feature of Mason.
Yes, Mason and TT both work this way.
> - I'm not sure how I feel on this issue: I want my templates to be limited
> in what data they can access, but I also don't want to have to specify or
> pass the exact data my template will use to the template system. When the
> HTML people want to add a new field on the page I don't want to have to
> always go into the application and provide that new data to the template --
> and that defeats one of the purposes of the template system.
How's that cake you're eating? Seriously, the best you can do is probably
to use a pipeline model and build data providers according to a certain
design that some other part of your program will recognize and
automatically make their data available to templates. Plugins, basically.
- Perrin
