Hi all-- brand new to the list, but I've been using HTML::Template for
some time. Just to quickly introduce myself... I work at Six Apart as
one of the engineers of Movable Type.  MT uses HTML::Template for all
of its application UI.


I'd like to request that HTML::Template provide more useful contextual
information to any user-supplied coderefs through filters and template
parameters that are coderefs.


First, for filters: a filter should be able to determine what file is
currently being processed, if the contents of the template did come
from a file.  I was able to find the HTML::Template package variable
that has a filename ($HTML::Template::fname), but it's the filename of
the parent of the template that is passed to the filter, not the
filename of the template being processed by the filter.  So, if I have
foo.tmpl:

    <TMPL_INCLUDE NAME=bar.tmpl>

When I process foo.tmpl with a filter parameter, the filter is invoked
once for foo.tmpl, then again for bar.tmpl.  The
$HTML::Template::fname set during the second call is for foo.tmpl. 
And, it would be helpful if the reference to the template object was
passed to the filter too.

I don't see any way to currently get either of these things.  I've
attached a patch for version 2.8 that adds what I'm looking for; at
the very least, it may help explain what I'm wanting.


Second, for template vars that are coderefs.

To me, these are a bit limited since the coderef has no way to
determine it's context.  I'm envisioning a scenario like this:

    <TMPL_LOOP NAME=X>
        <TMPL_VAR NAME=CODE_FOO>
    </TMPL_LOOP>

The coderef associated with 'code_foo' is called for each iteration of
the array in parameter 'x', but 'code_foo' has no way to access the
active row of data. Futhermore, it doesn't even know what parameter
name is being used to invoke it. If I were to assign the same coderef
for 'CODE_FOO' and 'CODE_BAR', the routine could do different things
based on the param name. Within a loop like this, it would be cool if
it could access the loop contextual values like "__first__", etc. It
would also be helpful to know if the coderef was being run from within
a loop, and what the name of that loop is. If it were in a loop within
a loop, within a loop, in file "x.tmpl", it should be able to
determine all that. I realize this would require some significant
changes; by the time the output method is run, the parameter names
aren't available. Perhaps if a coderef var is found during the parse
step, it could wrap it with a closure that supplies the context to the
original coderef.

-Brad

Attachment: Template.patch
Description: Binary data

Reply via email to