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
Template.patch
Description: Binary data