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" <[EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
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
Html-template-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/html-template-users
