html-template-users

[htmltmpl] Request for more contextual data to filters and coderef vars

[Brad C. <bc...@gm...>]

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=3Dbar.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.=20
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=3DX>
        <TMPL_VAR NAME=3DCODE_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

Re: [htmltmpl] Request for more contextual data to filters and coderef vars

[Sam T. <sa...@tr...>]

On Sat, 25 Feb 2006, Brad Choate wrote:

> 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.

Hey Brad, good to meet you.  I believe I owe my mention in the book
"We Blog" to Six Apart.  I'll let you decide if that's a good thing or
not.

> 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 guess that makes sense.  I'm curious though - what are you planning
to do with this feature?

> 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.

This seems less obviously useful to me.  If the data-structure for
loop X is so complicated then why make it more complicated by using
code-refs?  Why not just bake it all into the structure you pass to
param() in the first place?

I should admit, I very rarely use code-ref params in my work.  They
seem to have a very limited utility.  I used them to implement
HTML::Template::Expr, but I wouldn't say I'm proud of that fact!

-sam

Re: [htmltmpl] Request for more contextual data to filters and coderef vars

[Brad C. <bc...@gm...>]

On 2/27/06, Sam Tregar <sa...@tr...> wrote:
> On Sat, 25 Feb 2006, Brad Choate wrote:
> > 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 guess that makes sense.  I'm curious though - what are you planning
> to do with this feature?

One of MT's biggest features is our plugin support. With an upcoming
release, plugins will be able to make changes to the application's
templates. To do this, the plugins can request to be notified when
processing a particular template. Ie, the "menu" template. There are
others though, such as the common header and footer templates that
they can also target, but these are pulled in through the TMPL_INCLUDE
tag.  I can use the HTML::Template filter parameter to know when the
includes are processed, but I don't know what filename is being loaded
at the time.



> > 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=3DX>
> >        <TMPL_VAR NAME=3DCODE_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.
>
> This seems less obviously useful to me.  If the data-structure for
> loop X is so complicated then why make it more complicated by using
> code-refs?  Why not just bake it all into the structure you pass to
> param() in the first place?
>
> I should admit, I very rarely use code-ref params in my work.  They
> seem to have a very limited utility.  I used them to implement
> HTML::Template::Expr, but I wouldn't say I'm proud of that fact!

I don't use them either-- I just found out HTML::Template supported
them! I just find it odd that the coderef has no means to determine
the context in which it was invoked. Perhaps if it could, it would be
more useful? The current implementation seems to be just enough
implementation to support HTML::Template::Expr and nothing more.