On Mon, 8 Dec 2003, Puneet Kishor wrote:
> speaking of which, I have often wondered what could be improved in H-T,
> and have failed to come up with anything. It just seems to be that
> perfect program that does perfectly what it said to do. Simple to
> install and understand, well-documented, and fast. In fact, imho, it
> should be made a core part of Perl as is CGI.pm.
> But, since not being able to visualize the form of H-T's future might be
> due to my lack of imagination, I am curious -- what are the ways in
> which the developer-kind want to see H-T to be in a few years/versions
> or so...
I've considered doing an HTML::Template version 3 a few times, but
never found the time to do it. I even went so far as to draft a
design document. Here it is! (Note, I have no plans to actually do
this work anytime soon.)
=head1 HTML Template Version 3
HTML::Template needs work. The module is being put to uses today that
are far outside the scope of the original design. Adventures in
syntax enhancement (tmpl_if, HTML::Template::Expr, filter),
performance enhancement (HTML::Template::JIT) and CGI frameworks
(CGI::Application, HTML::Pager) have pushed HTML::Template's code to
the limit. Options have been added incrementally, and the complexity
of the code has grown exponentially with each addition (global_vars,
However, I have no plans to throw the baby out with the bath-water. I
think HTML::Template has a lot going for it. First, it's fast and
that won't change. Second, the default template syntax is, in my
never humble opinion, basically perfect. Finally, the API is pretty
good. In particular, the simplicity of new(), param() and output() is
not something I want to mess with.
So, what am I going to change? Here's an unordered list of
possibilities. Take a look through and tell me what you think. Am I
out of my mind? Did I leave out the feature you've always wanted?
Pluggable interface for parsers, file loaders, parameter collectors,
cachers, compilers and executors. I want to break up HTML::Template's
implementation into a handful of well-defined modules. Each of these
modules will have an interface which may be implemented independently.
This will make building stuff like HTML::Template::Expr and
HTML::Template::JIT much easier, as well as opening up the field for
simpler, faster implementations of the standard components.
Make the parser module accessible outside of HTML::Template. This
will make building tools that work with HTML::Template format
templates much simpler.
Pluggable interface for custom tags and attributes. You'd think after
writing HTML::Template::Expr I'd realize that this was a necessity,
but it still feels like treason. However, I think I'm just going to
have to accept that people are going to want to invent their own tags.
Making them use a filter is just not convenient enough.
This should also address the recurring ESCAPE=foo requests.
Make global_vars=1 the default mode and build it in right from the
start. It's what everyone expects when they first use the module and
I think it was a mistake to have it default off. In fact, I lean
towards removing the option entirely.
Parse and cache <tmpl_include>s separately. This will break some
things that currently work, like putting the top of a <tmpl_loop> in
one include and the </tmpl_loop> in another. However, for the vast
majority of uses this should provide a nice decrease in memory usage
and increase in performance.
Work out a mechanism for variable includes. With include files being
parsed and cache separately this is will probably be easier.
Better user-error detection. Many common cases could be caught
automatically and reported to the user. For example, assigning a loop
row the same hash-ref multiple times should trigger an error.