html-template-users

[htmltmpl] Variable in TMPL_INCLUDE

[Jason Y. <ja...@co...>]

Searching the mailing list, a few people have mentioned a patch for 
allowing variable filenames for the TMPL_INCLUDE tag.  Something like this:

$t->param(FILE => 'some_file.tmpl');

<TMPL_INCLUDE NAME="FILE">

I'm currently getting around this problem by loading two templates and 
outputing one into a variable of another.  It works but it is kind of a 
hack.  I'm wondering if anyone's made a patch for this feature.  If 
not,  I'd probably hack one out.

Re: [htmltmpl] Variable in TMPL_INCLUDE

[Mathew R. <mat...@re...>]

This is my local stable version of H::T (and releated modules).  This =
version has lot of changes, but you will want to use the =
'recursive_templates' argument =3D> set it to the depth that you will =
allow recursion.

CAVEAT:  Allowing recursive TMPL_INCLUDE's seriously breaks your ability =
to debug bad templates.  This is becuase H::T will die with a message =
saying something like "TMPL_INCLUDE blah", which makes it kind of hard =
to figure out if the current H::T output contains a valid TMPL_INCLUDE, =
or an error message.  In the future I hope to solve this problem...

Hope this helps,
Mathew



----- Original Message -----=20
From: "Jason Yates" <ja...@co...>
To: <htm...@li...>
Sent: Monday, April 05, 2004 12:49 PM
Subject: [htmltmpl] Variable in TMPL_INCLUDE


> Searching the mailing list, a few people have mentioned a patch for=20
> allowing variable filenames for the TMPL_INCLUDE tag.  Something like =
this:
>=20
> $t->param(FILE =3D> 'some_file.tmpl');
>=20
> <TMPL_INCLUDE NAME=3D"FILE">
>=20
> I'm currently getting around this problem by loading two templates and =

> outputing one into a variable of another.  It works but it is kind of =
a=20
> hack.  I'm wondering if anyone's made a patch for this feature.  If=20
> not,  I'd probably hack one out.
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

Re: [htmltmpl] Variable in TMPL_INCLUDE

[Puneet K. <pk...@ei...>]

On Apr 4, 2004, at 11:03 PM, Mathew Robertson wrote:

> This is my local stable version of H::T (and releated modules).  This 
> version has lot of changes, but you will want to use the 
> 'recursive_templates' argument => set it to the depth that you will 
> allow recursion.
>
> CAVEAT:  Allowing recursive TMPL_INCLUDE's seriously breaks your 
> ability to debug bad templates.  This is becuase H::T will die with a 
> message saying something like "TMPL_INCLUDE blah", which makes it kind 
> of hard to figure out if the current H::T output contains a valid 
> TMPL_INCLUDE, or an error message.  In the future I hope to solve this 
> problem...
>
> Hope this helps,
> Mathew
>
>
>
> ----- Original Message -----
> From: "Jason Yates" <ja...@co...>
> To: <htm...@li...>
> Sent: Monday, April 05, 2004 12:49 PM
> Subject: [htmltmpl] Variable in TMPL_INCLUDE
>
>
>> Searching the mailing list, a few people have mentioned a patch for
>> allowing variable filenames for the TMPL_INCLUDE tag.  Something like 
>> this:
>>
>> $t->param(FILE => 'some_file.tmpl');
>>
>> <TMPL_INCLUDE NAME="FILE">
>>
>> I'm currently getting around this problem by loading two templates and
>> outputing one into a variable of another.  It works but it is kind of 
>> a
>> hack.  I'm wondering if anyone's made a patch for this feature.  If
>> not,  I'd probably hack one out.
>>
>>

I thought this problem was solved with judicious use of filters. There 
are enough posts on this in the archives. Am I missing something here? 
Or are folks simply averse to using filters?

Re: [htmltmpl] Variable in TMPL_INCLUDE

[Jason Y. <ja...@co...>]

Puneet Kishor wrote:

> I thought this problem was solved with judicious use of filters. There 
> are enough posts on this in the archives. Am I missing something here? 
> Or are folks simply averse to using filters?


In my case,  I pull a id from a database and then load the template with 
that id.  For instance, I'll pull id 5 and the template will be named 
5.tmpl.  There is no ability with filters to pass that id to the filter 
function.  So in my case, I'd have to create another CGI object grab 
relevents paramaters, load the DBI object reconnect to the database,  
and query the database for the id.  Filters just won't work well for 
what I'm trying to do.  Especially if there are a number of includes, 
the above process could be run 4-5 times.  It would be extremely slow.

Re: [htmltmpl] Variable in TMPL_INCLUDE

[Cees H. <ce...@si...>]

Jason Yates wrote:
> Puneet Kishor wrote:
> 
>> I thought this problem was solved with judicious use of filters. There 
>> are enough posts on this in the archives. Am I missing something here? 
>> Or are folks simply averse to using filters?
> 
> In my case,  I pull a id from a database and then load the template with 
> that id.  For instance, I'll pull id 5 and the template will be named 
> 5.tmpl.  There is no ability with filters to pass that id to the filter 
> function.  So in my case, I'd have to create another CGI object grab 
> relevents paramaters, load the DBI object reconnect to the database,  
> and query the database for the id.  Filters just won't work well for 
> what I'm trying to do.  Especially if there are a number of includes, 
> the above process could be run 4-5 times.  It would be extremely slow.

You can use variables in your filters through the use of a closure.  So 
you don't have to create a new CGI object and database connection... 
Here is some psuedo code to explain how to do it:

my $dbh = ... Get DB handle ...

my $template = HTML::Template->new(
       filename => 'zap.tmpl',
       filter => sub {
                       my $text_ref = shift;
                       my $sth = $dbh->prepare('... SQL ...');
                       ...
                     },

});

the anonymous subroutine will act as a closure with respect to $dbi. 
See the perldocs for 'perlsub' for more on closures.

But there is a problem with using filters that alter the template 
dynamically.  The caching mechanism fails to take into consideration 
anything that is done with the filters.  In other words, after the first 
time your filter gets run, the resulting template will be cached, and 
the filter will not be executed again the next time the template is 
called (ie on the next request).

So if your filters change dynamically based on some parameter, then you 
must turn off caching.  Check the archives for more discussions on this.

Cees

Re: [htmltmpl] Variable in TMPL_INCLUDE

[Mathew R. <mat...@re...>]

> I thought this problem was solved with judicious use of filters. There =

> are enough posts on this in the archives. Am I missing something here? =

> Or are folks simply averse to using filters?

As others have stated - sometimes filters can be used to solve the =
problem; in other cases, using a TMPL_VAR as part of the TMPL_INCLUDE is =
the simplest solution that presents itself.

Mathew