Re: [htmltmpl] Variable in TMPL_INCLUDE
Brought to you by:
samtregar
From: Cees H. <ce...@si...> - 2004-04-05 19:17:40
|
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 |