html-template-users

[htmltmpl] Dynamic Filters for cached templates forced recall ?

[Chris N. <chr...@in...>]

Hi,
	I want to be able to run HTML::Template::JIT or standard cached 
HTML::Template with a dynamic filter. I have run a filter which contains a 
call to a subroutine which does a remote data retrieval socket GET but it 
appears that HTML::Template is not dynamically re-calling this routine. I 
have looked at the Inline C for the JIT template and the remote data is just 
embedded as a normal string. Is there anyway to make this subroutine call be 
forced to be called every time (without switching off caching or sacrificing 
the JIT stuff) ?
	I have looked at alternatives such as building something into Apache to scan 
the delivered pages and re-parse a tag which I'd flag as dynamic but ideally 
want to be able to use the HTML::Template constructs on the dynamic data.
	Apologies if I'm missing something obvious.

Chris

Re: [htmltmpl] Dynamic Filters for cached templates forced recall ?

[Chris N. <chr...@in...>]

Oops. I've since been running an Apache/mod_perl combo with 
HTML::Template::JIT memory resident and have shifted the data population of 
the template to the mod_perl script using it a request processor as I should 
have realised originally. I'm now thinking of the template engine a bit like 
an SQL skeleton prepare statement. I was putting the data where the ? should 
have been.
Here's some interesting benchmarks for a simplistic template but shows the 
sheer power of the mod_perl/Apache combo:

Benchmark: timing 1000 iterations of cgi-cache, cgi-jit, cgi-nojit, 
modperl-cache, modperl-jit, modperl-nojit...
 cgi-cache: 257 wallclock secs ( 1.46 usr +  0.68 sys =  2.14 CPU) @ 467.29/s 
(n=1000)
   cgi-jit: 256 wallclock secs ( 1.27 usr +  0.54 sys =  1.81 CPU) @ 552.49/s 
(n=1000)
 cgi-nojit: 219 wallclock secs ( 1.15 usr +  0.52 sys =  1.67 CPU) @ 598.80/s 
(n=1000)
modperl-cache:  6 wallclock secs ( 1.39 usr +  0.47 sys =  1.86 CPU) @ 
537.63/s (n=1000)
modperl-jit:  5 wallclock secs ( 1.41 usr +  0.47 sys =  1.88 CPU) @ 531.91/s 
(n=1000)
modperl-nojit:  6 wallclock secs ( 1.45 usr +  0.51 sys =  1.96 CPU) @ 
510.20/s (n=1000)

marvellous.


On Thursday 11 July 2002 12:50, Chris Newman wrote:
> Hi,
> 	I want to be able to run HTML::Template::JIT or standard cached
> HTML::Template with a dynamic filter. I have run a filter which contains a
> call to a subroutine which does a remote data retrieval socket GET but it
> appears that HTML::Template is not dynamically re-calling this routine. I
> have looked at the Inline C for the JIT template and the remote data is
> just embedded as a normal string. Is there anyway to make this subroutine
> call be forced to be called every time (without switching off caching or
> sacrificing the JIT stuff) ?
> 	I have looked at alternatives such as building something into Apache to
> scan the delivered pages and re-parse a tag which I'd flag as dynamic but
> ideally want to be able to use the HTML::Template constructs on the dynamic
> data. Apologies if I'm missing something obvious.
>
> Chris
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] [patch] __counter__ variable

[simran <sim...@le...>]

i All, 

I sent the patch below (for a __COUNTER__) variable if loop_context_vars
was on - a while ago, but did not hear anything about it... maybe people
didn't find it that useful (or maybe it didn't make it to the list). 

Anyhow, Sam, what do you think about the patch below? 

It would be useful with pringing lists where you want them numbered, 
and also for things like:

  <tmpl_expr name="__COUNTER__ % 7">
    <tr>
  </tmpl_expr>
  for Table tr's if using a the HTML::Template::Expr template... 

simran.

On Thu, 2002-04-18 at 09:40, simran wrote:
> Hi All, 
> 
> There has recently been brief mention/discussion of the need for a
> 'counter' variable in a loop. 
> 
> Finding such a feature invaluable myself, i have included a patch
which
> makes a '__COUNTER__' variable available if loop_context_vars is
turned
> on (i had version 2.4 of HTML::Template).
> 
> Hope it makes it into the core... sam? 
> 
> kind regards, 
> 
> simran.
> 
> *** Template.pm.orig  Thu Apr 18 09:25:07 2002
> --- Template.pm Thu Apr 18 09:30:56 2002
> ***************
> *** 617,629 ****
>   default) four loop context variables are made available inside a
loop:
>   __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
>   <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
> ! output.  Example:
> 
>      <TMPL_LOOP NAME="FOO">
>         <TMPL_IF NAME="__FIRST__">
>           This only outputs on the first pass.
>         </TMPL_IF>
> 
>         <TMPL_IF NAME="__ODD__">
>           This outputs every other pass, on the odd passes.
>         </TMPL_IF>
> --- 617,636 ----
>   default) four loop context variables are made available inside a
loop:
>   __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
>   <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
> ! output.
> !
> ! In addition to the above, a __COUNTER__ VAR is also made available
> ! when loop context variables are turned on.
> !
> ! Examples:
> 
>      <TMPL_LOOP NAME="FOO">
>         <TMPL_IF NAME="__FIRST__">
>           This only outputs on the first pass.
>         </TMPL_IF>
> 
> +       <TMPL_VAR NAME="__COUNTER__">
> +
>         <TMPL_IF NAME="__ODD__">
>           This outputs every other pass, on the odd passes.
>         </TMPL_IF>
> ***************
> *** 1860,1869 ****
>     # die_on_bad_params set output() will might cause errors
>     # when it tries to set them.
>     if ($options->{loop_context_vars}) {
> !     $pmap{__first__} = HTML::Template::VAR->new();
> !     $pmap{__inner__} = HTML::Template::VAR->new();
> !     $pmap{__last__} = HTML::Template::VAR->new();
> !     $pmap{__odd__} = HTML::Template::VAR->new();
>     }
>         } elsif ($which eq '/TMPL_LOOP') {
> --- 1867,1877 ----
>     # die_on_bad_params set output() will might cause errors
>     # when it tries to set them.
>     if ($options->{loop_context_vars}) {
> !     $pmap{__first__}   = HTML::Template::VAR->new();
> !     $pmap{__inner__}   = HTML::Template::VAR->new();
> !     $pmap{__last__}    = HTML::Template::VAR->new();
> !     $pmap{__odd__}     = HTML::Template::VAR->new();
> !     $pmap{__counter__} = HTML::Template::VAR->new();
>     }
> 
>         } elsif ($which eq '/TMPL_LOOP') {
> ***************
> *** 2731,2741 ****
>           @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
>         }
>         $odd = $value_set->{__odd__} = not $odd;
>       }
>       $template->param($value_set);
>       $result .= $template->output;
>       $template->clear_params;
> !     @{$value_set}{qw(__first__ __last__ __inner__ __odd__)} =
> (0,0,0,0)
>         if ($loop_context_vars);
>       $count++;
>     }
> --- 2739,2750 ----
>           @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
>         }
>         $odd = $value_set->{__odd__} = not $odd;
> +       $value_set->{__counter__} = $count + 1;
>       }
>       $template->param($value_set);
>       $result .= $template->output;
>       $template->clear_params;
> !     @{$value_set}{qw(__first__ __last__ __inner__ __odd__
> __counter__)} = (0,0,0,0,0)
>         if ($loop_context_vars);
>       $count++;
>     }