No filter on includes?

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

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

_______________________________________________
Html-template-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/html-template-users