Re: [htmltmpl] No filter on includes?

[Vijay R. <vij...@po...>]

So, I found a different way to solve this problem, by making the append JSON-dump not a filter, but rather an additional process step after getting the HTML::Template output, before sending it back to the mod_perl script (we have a Web-App layer in-between the two).  Since I'm able to access $template->{options}->{some_created_option} I was able to use that to store the JSON-dump and access it after doing $template->output (calling HTML::Template output).

If anybody else still sees the need for having a "no_filter_includes" (for example, when including external templates?) the code below should still allow for this, but I officially withdraw my request!



On 7/26/08 12:56 PM, "Vijay Ramesh" <vij...@po...> wrote:

I've been running into an issue with a Web-App system the company I work for has built around HTML::Template.  Basically, to summarize the problem, I am creating a JSON-dump of everything in the handler (e.g., all tmpl_*, including a bunch of environmental, config, and session stuff that we set automatically) and - given a parameter on this our-Web-App=>HTML::Template=>parse call, want to append this JSON-dump as a div at the bottom of the template. It is then loaded by a javascript object that uses it to generate ajax-calls among other things. Anyhow, the problem isn't with this, per se, but with the way that HTML::Template automatically applies filters to all tmpl_includes.  I can get around this by some nasty regexps before sending the output of the parsed template, making sure only one JSON-dump div is present, but that really breaks the whole programming/design paradigm (that I like very much).  Now, there might be a better way to append this generated JSON-dump as a TMPL_VAR to the end of the parsed template than using a filter (as using a filter comes pretty close to adding design - e.g., appending a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ to the template as a filter) but this current method works well, making it so the individual mod_perl script does not have to do anything except set a parameter in the custom parse call indicating this JSON-dump should be created and appended to the output.  I really don't want to lose this automation - and so am resigned to having the slightest bit of HTML + TMPL_VAR in an App-level filter. But, so long as filters automatically run for all tmpl_includes as well, I'm ending up with as many of these divs as there are tmpl_includes, plus one for the main template.  Now, I certainly understand why - as they are normally used - filters run for all tmpl_includes. What I was wondering was would it be terrible to add a "no_filter_includes" parameter to the HTML::Template parse call, and then having something like

$self->_call_filters(\$included_template) if @{$options->{filter}} && $options{no_filter_includes} != 1

At line 2252 of HTML::Template 2.8?

That would be the only change required - and it wouldn't effect anything if the option isn't set (i.e., it wouldn't mess up existing uses of HTML::Template).  I'm not sure if anybody else has ever had cause for a similar option, or if my use of filters is just too far off the HTML::Template paradigm to warrant this change, but it would save me from having some nasty regexp parsing after getting the output....

I would gladly commit this change - or anybody who is actively working with the project, you'd just have to make the change detailed above - if anybody else sees this as a potentially beneficial  option to have? Or if anybody has suggestions for a different way to append a qq/<div id="js_thandler"><TMPL_VAR ESCAPE=HTML JS_THANDLER><\/div>/ line to the template before it gets parsed without using a filter, that'd be great as well.

Thanks for the input
/ Vijay K Ramesh