I have to say that I am also interested in template kits myself.
My requirements are almost identical to yours (minus a few advanced things).
Basically, I write open source web applications in Perl -- that means that
they must be able to run reasonably fast on non-modperl systems and must
run on a variety of ISPs (ie not dedicated servers where you control the
version of Perl).
Of course, mod_perl support is crucial for those that want to "scale", but
normal CGI/Perl support is really a biggie that I haven't seen highlighted
within the context of this thread.
Here are my CGI/Perl requirements:
1) Must be 100% pure Perl or support pure-Perl alternatives if certain libs
arent compiled. Many people who download CGI scripts don't know how to
compile stuff.
2) Must support Perl 5.004 and above. Ideal to support Perl 5.003. Enough
ISPs and corporations around the world are still on 5.004 that only
supporting the latest Perl version is not doable.
3) Must incur as minimal load-time as possible. CGI/Perl scripts are not
cached like mod_perl scripts.
So CGI/Perl people must have a template system that can choose to load a
minimal amount of code if really advanced features aren't used. IE would
rather not have a templating system as large as CGI.pm. Or rather it can be
as large as CGI.pm, but only if the extra code is loaded when advanced
features are accessed -- normal CGI/Perl users should not be penalized.
4) Must have a license that supports redistribution in other scripts. I
think most of the systems out there do that (maybe all the Perl ones do).
CPAN is great for us, but again, most real-world web app users are not CPAN
savvy and don't have the rights to install global modules on their ISP nor
the learning to install them locally. So an open source web app that takes
advantage of a template system really should also contain that template
system. The power users can remove it from the local dir if they have a
globally installed version of the system.
Anyway, I felt that I should state these feature requirements because this
list is so mod_perl centric, I think sometimes we forget the "little"
people. And there are many more of them out there than mod_perl servers and
Perl/CPAN savvy people.
<RANT_IN_ADVANCE>And please don't say that they should RTFM. Most users do
not have time to RTFM. If they did, they would be us. :) These users are
people who know their business and typically learn just enough tech to
install something that will help their business -- they don't care or want
a CS degree in the process.</RANT_IN_ADVANCE>
Later,
Gunther
At 09:45 AM 8/1/00 -0700, Bill Moseley wrote:
>It seems as if there needs to be a general templating mailing list...
>
>Here I have a comment about comparing template systems, and then I solicit
>advice on which system to use...
>
>The only reason I'm using my own templating system (besides the requirement
>that everyone writes one) is because I realized it would take me less time
>to code up a simple one than wade through all the available packages,
>downloading, installing, and trying each out. And frankly, some are so
>feature-rich that they scared me off - I wanted a template system in my
>application, not the other way around.
>
>I really should leave the programming to The Experts, so having a nice
>comparison of features would be a huge help, and it might have convinced me
>to pick one of the available systems.
>
>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.
>
>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. Maybe this is an
>incorrect assumption?
>
>I'd also like to see and compare which ones are designed to work best with
>mod_perl, and the benefits that mod_perl provides the system.
>
>It seems like each of the various templating web sites have great info, but
>it would just be very helpful to see it in one place and see each compared
>against the others.
>
>
>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?
>
>Here is what I need:
>
>- Get HTML out of my code, but limit code in templates as non-perl people
>will be editing the templates -- although I need ways to do some tricks in
>the templates like changing the bgcolor of a row of a table if some
>condition is met, or adding an additional column to every row if data in
>one row meets some condition.
>
>- Shared template cache across server children, 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).
>
>- Not sure if it makes much difference in speed, but parts of my templates
>only need to be filled in when first loaded off disk since the data is
>static once loaded (e.g. base url, base path, titles). Other parts are
>filled in with each request, as is common.
>
>- Easy way to handle co-branding (partners/views). I have a site that is
>used by a number of other sites -- basically our site is wrapped in their
>"look".
>
>Admittedly, I could probably use a better design. My program maps various
>pages of the application (e.g. main page, search page, results page, error
>page, help page) to different template files.
>
>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.
>
>- 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.
>
>
>So, any suggestions on what one or two templating systems I should try that
>would do at least the above?
>
>Thanks,
>
>Bill Moseley
>mailto:[EMAIL PROTECTED]
__________________________________________________
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
