html-template-users — Discussion of HTML::Template and related modules

Re: [htmltmpl] HTML::Template tutorials

[Karen <kar...@gm...>]

On 8/1/07, Chris Henden <chr...@bb...> wrote:
> I'm looking for a nice tutorial on HTML::Template authoring, aimed at
> a client-side developer, without any references to perl techniques
> (or perl references...).

There's some documentation on that order in the python "port", though
you'll have to allow for  differences in the implementation. But it's
a start:

http://htmltmpl.sourceforge.net/lang.html

[htmltmpl] HTML::Template tutorials

[Chris H. <chr...@bb...>]

Hi all,
I'm looking for a nice tutorial on HTML::Template authoring, aimed at  
a client-side developer, without any references to perl techniques  
(or perl references...).

All the ones I can find have explanations of the tags, and loops -  
but mixed up with confusing talk about arrays etc, which ideally our   
html developer doesn't need to know about.

Can anyone point me in the right direction?

many thanks in advance,
Chris

Re: [htmltmpl] Filter Syntax

[Robert H. <si...@gm...>]

Chris Faust wrote:
> Folks,
> 
>  
> 
> I'm having (what I hope is) a syntax problem.
> 
>  
> 
> I'm trying to use the "filter" option to run a sub on a template at 
> create time, but I want the sub in another package and I need to some 
> other objects with it.
> 
>  
> 
>  From reading the docs I thought that the HTML::Template object would 
> simply be the first incoming param, but its not.
> 
>  
> 
> For example, here is how I wanted to create my template object:
> 
>  
> 
>  my $template_header = new HTML::Template(filename => 'CommonHeader.tmpl',
>            filter  => { sub => 
> scripts::MyPackage->initialize_template_header($r,$db,$site_settings,$user_session_data,\%form_data) 
> },
>            );
> 
>  
> 
> Then in "MyPackage.pm", I would have
> 
>  
> 
> sub initialize_template_header {
>  my 
> ($self,$template,$r,$db,$site_settings,$user_session_data,$form_data) = @_;
> ....
> 
> }
> 
>  
> 
> $self is correctly defined, but $template becomes the first object I 
> send in ($r in this case).
> 
>  
> 
> How do I get the HTML::Template object??
> 


This may have an answer for you:

http://www.perl.com/pub/a/2006/11/30/html-template-filters.html

HTH

Robert

[htmltmpl] Filter Syntax

[Chris F. <cf...@do...>]

Folks,

 

I'm having (what I hope is) a syntax problem.

 

I'm trying to use the "filter" option to run a sub on a template at create
time, but I want the sub in another package and I need to some other objects
with it.

 

>From reading the docs I thought that the HTML::Template object would simply
be the first incoming param, but its not.

 

For example, here is how I wanted to create my template object:

 

 my $template_header = new HTML::Template(filename => 'CommonHeader.tmpl',
           filter  => { sub =>
scripts::MyPackage->initialize_template_header($r,$db,$site_settings,$user_s
ession_data,\%form_data) },
           );

 

Then in "MyPackage.pm", I would have

 

sub initialize_template_header {
 my ($self,$template,$r,$db,$site_settings,$user_session_data,$form_data) =
@_;
....

}

 

$self is correctly defined, but $template becomes the first object I send in
($r in this case).

 

How do I get the HTML::Template object??

 

TIA!!

-Chris

 

 

Re: [htmltmpl] apache and html template

[Blesson P. <ble...@ya...>]

Hi,

I done the same thing in my code. The result, the
charecter ś is showing correctly in edit box of
IE. But  when it is part of HTML, it is corrupted. 

I think OS is doing the formatting of charecters in
the Edit Box. But when it is a part of HTML, borwser
is doing the formatting. 

Any clue how to fix it

Thanks
Blesson paul
--- Sven Neuhaus <sve...@sv...> wrote:

> Blesson Paul wrote:
> > > I have an issue with Polish character &#347;.
> This
> > > charecter is corrupted when it is outputed
> through
> > > HTML::Template->output().
> > >
> > > Only this charecter is causing the issue. Rest
> of them
> > > are fine. Is there any solution to solve this
> 
> &#347; is an "s-acute", right? "ś" to be exact.
> 
> It works here using this test script in a
> utf8-xterm:
> 
> perl -MHTML::Entities -MHTML::Template -e
> '$a=decode_entities("&#347;");
>  $c=q{<TMPL_VAR NAME="t">};
> $b=HTML::Template->new(scalarref=>\$c);
>  $b->param("t"=>$a); binmode(STDOUT, ":utf8"); print
> $b->output;'
> 
> When I pipe the output of this script into "od -t
> x1" I get the correct
> output "c5 9b".
> 
> Does it only happen when run inside
> -Sven
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
>
https://lists.sourceforge.net/lists/listinfo/html-template-users
> 



      ____________________________________________________________________________________
Luggage? GPS? Comic books? 
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

Re: [htmltmpl] HTML::Template support for Unicode

[Erik v. K. <ek...@xs...>]

On Sat, 2007-07-21 at 18:15 +0200, Sven Neuhaus wrote:
> Erik van Konijnenburg schrieb:
> > On Fri, 2007-07-20 at 09:58 +0200, Sven Neuhaus wrote:
> >> Erik van Konijnenburg schrieb:
> >>> This is to propose for inclusion in HTML::Template a patch that
> >>> adds unicode support.
> >>> If the template file happens to contain Unicode already, this breaks:
> >>> the bytes making up an UTF-8 character are fed to the Latin => unicode
> >>> transformation, and you end up with characters that are encoded twice.
> >> I have seen this problem "in the wild", too.
> >>
> >>> There are some ways to handle this situation:
> >> There is another way that is not quite as inconvenient: You can pass a
> >> filehandle to the constructor:
> >>
> >>    open($fh, '<:utf8', 'template-file');
> >>    my $t = HTML::Template->new(filehandle => $fh);
> > Yep, that would work, provided you don't need include files.
> 
> Now that you mention it, I guess the TMPL_INCLUDE tag would need an 
> attribute "encoding" to allow mixed setups. Or is that more of a 
> hypothetical scenario?

Hmm, good point.  The proposed patch allows nested includes in say
unicode or latin-5, but does not allow you to include a latin-5
template from within a unicode template.  An "encoding" attribute
for TMPL_INCLUDE would make that possible, but it would be necessary
to define what happens with deeply nested tmpl_includes, where only some
of them have an encoding attribute.  Obviously such constructs are
error-prone in practice and would require quite a few different test
cases in the suite.

Without bug-reports from users that actually try to run such a setup,
I would declare the issue hypothetical and avoid the added complexity.

> Thanks,
> -Sven

Regards,
Erik

Re: [htmltmpl] HTML::Template support for Unicode

[Sven N. <sve...@sv...>]

Erik van Konijnenburg schrieb:
> On Fri, 2007-07-20 at 09:58 +0200, Sven Neuhaus wrote:
>> Erik van Konijnenburg schrieb:
>>> This is to propose for inclusion in HTML::Template a patch that
>>> adds unicode support.
>>> If the template file happens to contain Unicode already, this breaks:
>>> the bytes making up an UTF-8 character are fed to the Latin => unicode
>>> transformation, and you end up with characters that are encoded twice.
>> I have seen this problem "in the wild", too.
>>
>>> There are some ways to handle this situation:
>> There is another way that is not quite as inconvenient: You can pass a
>> filehandle to the constructor:
>>
>>    open($fh, '<:utf8', 'template-file');
>>    my $t = HTML::Template->new(filehandle => $fh);
> Yep, that would work, provided you don't need include files.

Now that you mention it, I guess the TMPL_INCLUDE tag would need an 
attribute "encoding" to allow mixed setups. Or is that more of a 
hypothetical scenario?

Thanks,
-Sven

Re: [htmltmpl] HTML::Template support for Unicode

[Erik v. K. <ek...@xs...>]

On Fri, 2007-07-20 at 09:58 +0200, Sven Neuhaus wrote:
> Erik van Konijnenburg schrieb:
> > This is to propose for inclusion in HTML::Template a patch that
> > adds unicode support.
> 
> > If the template file happens to contain Unicode already, this breaks:
> > the bytes making up an UTF-8 character are fed to the Latin => unicode
> > transformation, and you end up with characters that are encoded twice.
> 
> I have seen this problem "in the wild", too.
> 
> > There are some ways to handle this situation:
> 
> There is another way that is not quite as inconvenient: You can pass a
> filehandle to the constructor:
> 
>    open($fh, '<:utf8', 'template-file');
>    my $t = HTML::Template->new(filehandle => $fh);
Yep, that would work, provided you don't need include files.

> However, I agree that the option you patch adds is quite convenient.
Thanks :-)

> Care to add some tests for this problem, too?

Sure, apply http://www.xs4all.nl/~ekonijn/html-template-unicode.patch
and have a look at t/04charset.t; this contains tests of katakana,
devangari and cyrillic, provided both in UTF-8 and Latin-5.

Non-ascii in a patch might be tricky; if the patch won't apply cleanly
let me know & I'll post a tarball.

> 
> -Sven

Regards,
Erik

Re: [htmltmpl] HTML::Template support for Unicode

[Sven N. <sve...@sv...>]

Erik van Konijnenburg schrieb:
> This is to propose for inclusion in HTML::Template a patch that
> adds unicode support.

> If the template file happens to contain Unicode already, this breaks:
> the bytes making up an UTF-8 character are fed to the Latin => unicode
> transformation, and you end up with characters that are encoded twice.

I have seen this problem "in the wild", too.

> There are some ways to handle this situation:

There is another way that is not quite as inconvenient: You can pass a
filehandle to the constructor:

   open($fh, '<:utf8', 'template-file');
   my $t = HTML::Template->new(filehandle => $fh);

However, I agree that the option you patch adds is quite convenient.
Care to add some tests for this problem, too?

-Sven

[htmltmpl] HTML::Template support for Unicode

[Erik v. K. <ek...@xs...>]

This is to propose for inclusion in HTML::Template a patch that
adds unicode support.

The 2.8 release of Html::Template opens templates as raw files.
That means every byte is interpreted as an individual character.
If a parameter contains wide characters (katakana, or accented latin
characters for example), then the bytes from the templates are made to
match the wide characters by translating the bytes to Unicode.  This is
done by interpreting the bytes as Latin-1 characters.

If the template file happens to contain Unicode already, this breaks:
the bytes making up an UTF-8 character are fed to the Latin => unicode
transformation, and you end up with characters that are encoded twice.

There are some ways to handle this situation:
    **	demand that parameters supplied to template processing
	don't contain wide characters.  All parameters must have
	been processed by Encode::encode before template expansion.
	This is inconvenient, especially if the parameters are used
	in more than one place.

    **	Supply a filter subroutine to the template that will do UTF
	decoding after the template file has been read, as follows:

	    my $tmpl = HTML::Template->new (filename => 'test.tmpl',
			filter => sub {
			    my $ref = shift;
			    ${$ref} = Encode::decode_utf8(${$ref});
			});

	This works, but is a bit ad-hoc: it was not immediately obvious
	to me that this filter is an opportunity to make Unicode work.

    **	Add a feature to HTML::Template to specify the encoding
	of template files.

I cooked up a patch that adopts the latter approach by adding an optional
"encoding" argument to the Template->new() function, like so:

    my $t = HTML::Template->new(
	filename => 'file.tmpl',
	encoding => ':encoding(UTF-8)');

The specified encoding is used not only for the template itself,
but also for any templates included from within the template.
Possible values for encoding are defined in perlio(3perl).
This also works fine with templates encoded in character
sets other than unicode or latin1.

The attached patch was made against 2.8, but applies to 2.9 with 
a small offset.  For now, a larger version is at:
http://www.xs4all.nl/~ekonijn/html-template-unicode.patch
(The larger version contains tests with a number of non-ascii characters,
so is tricky to send reliably over a mailing list)

Regards,
Erik



diff -urN org/libhtml-template-perl-2.8/Template.pm new/libhtml-template-perl-2.8/Template.pm
--- org/libhtml-template-perl-2.8/Template.pm	2007-07-05 21:40:40.000000000 +0200
+++ new/libhtml-template-perl-2.8/Template.pm	2007-07-09 17:27:11.000000000 +0200
@@ -885,6 +885,15 @@
 HTML::Template will apply the specified escaping to all variables
 unless they declare a different escape in the template.
 
+=item * 
+
+encoding - Set this to the name of a perlio layer to be used when
+doing open() on the template or an included template; default is ":bytes".
+As an example, to read a template containing unicode:
+
+   my $template = HTML::Template->new(filename => 'zap.tmpl',
+                                      encoding => ':utf8');
+
 =back
 
 =back 4
@@ -949,6 +958,7 @@
                vanguard_compatibility_mode => 0,
                associate => [],
                path => [],
+	       encoding => ':bytes',
                strict => 1,
                loop_context_vars => 0,
                max_includes => 10,
@@ -1635,8 +1645,9 @@
       $options->{filepath} = $filepath;   
     }
 
+    my $encoding = $options->{encoding};
     confess("HTML::Template->new() : Cannot open included file $options->{filename} : $!")
-        unless defined(open(TEMPLATE, $filepath));
+        unless defined(open(TEMPLATE, "<$encoding", $filepath));
     $self->{mtime} = $self->_mtime($filepath);
 
     # read into scalar, note the mtime for the record
@@ -2240,8 +2251,9 @@
 	}
 	die "HTML::Template->new() : Cannot open included file $filename : file not found."
 	  unless defined($filepath);
+	my $encoding = $options->{encoding};
 	die "HTML::Template->new() : Cannot open included file $filename : $!"
-	  unless defined(open(TEMPLATE, $filepath));              
+	  unless defined(open(TEMPLATE, "<$encoding", $filepath));              
 	
 	# read into the array
 	my $included_template = "";

Re: [htmltmpl] apache and html template

[Blesson P. <ble...@ya...>]

Hi,

yes it is correct 

cierpliwoś. is converted into cierpliwoś .



But I didn't understood the fix you suggested.

Thanks
BLesson Paul
--- Sven Neuhaus <sve...@sv...> wrote:

> Blesson Paul wrote:
> > > I have an issue with Polish character &#347;.
> This
> > > charecter is corrupted when it is outputed
> through
> > > HTML::Template->output().
> > >
> > > Only this charecter is causing the issue. Rest
> of them
> > > are fine. Is there any solution to solve this
> 
> &#347; is an "s-acute", right? "ś" to be exact.
> 
> It works here using this test script in a
> utf8-xterm:
> 
> perl -MHTML::Entities -MHTML::Template -e
> '$a=decode_entities("&#347;");
>  $c=q{<TMPL_VAR NAME="t">};
> $b=HTML::Template->new(scalarref=>\$c);
>  $b->param("t"=>$a); binmode(STDOUT, ":utf8"); print
> $b->output;'
> 
> When I pipe the output of this script into "od -t
> x1" I get the correct
> output "c5 9b".
> 
> Does it only happen when run inside
> -Sven
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
>
https://lists.sourceforge.net/lists/listinfo/html-template-users
> 



       
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/

Re: [htmltmpl] apache and html template

[Sven N. <sve...@sv...>]

Blesson Paul wrote:
> > I have an issue with Polish character ś. This
> > charecter is corrupted when it is outputed through
> > HTML::Template->output().
> >
> > Only this charecter is causing the issue. Rest of them
> > are fine. Is there any solution to solve this

ś is an "s-acute", right? "ś" to be exact.

It works here using this test script in a utf8-xterm:

perl -MHTML::Entities -MHTML::Template -e '$a=decode_entities("ś");
 $c=q{<TMPL_VAR NAME="t">}; $b=HTML::Template->new(scalarref=>\$c);
 $b->param("t"=>$a); binmode(STDOUT, ":utf8"); print $b->output;'

When I pipe the output of this script into "od -t x1" I get the correct
output "c5 9b".

Does it only happen when run inside
-Sven

Re: [htmltmpl] apache and html template

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

>From experience I can say that making UTF8 work reliably is a
non-trivial task, especially when trying to interact with the various
sub-systems. So...:

- do you have "use utf8;" at the top of the Perl module?

- how is that character entering the Perl interpretor?  ie: is it being
loaded from a file, a database, hand-coded inside the source file, etc.

- Is your HTML header setting the appropriate UTF8 strings so that the
browser is displaying the content correctly?

regards,
Mathew Robertson


Blesson Paul wrote:
> Hi,
>
> I have an issue with Polish character ś. This
> charecter is corrupted when it is outputed through
> HTML::Template->output(). 
>
> Only this charecter is causing the issue. Rest of them
> are fine. Is there any solution to solve this 
>
> Thanks
> blesson Paul
> --- Mathew Robertson
> <mat...@ne...> wrote:
>
>   
>> Hi Paul,
>>
>> Which version of Perl are you using?   I have used
>> 5.6.x and 5.8.x and
>> found that 5.8.3 or better was required for bug-less
>> operation.
>>
>> Mathew Robertson
>>
>> Blesson Paul wrote:
>>     
>>> My problem is same as this one
>>>
>>>       
> http://www.template-toolkit.org/pipermail/templates/2003-March/004314.html
>   
>>> Any fix for this.
>>>
>>> Thanks
>>> Blesson Paul
>>> --- Blesson Paul <ble...@ya...> wrote:
>>>
>>>   
>>>       
>>>> Just add to that, If I didn't do Template->param,
>>>> there is no issue. That means there is no issue
>>>>         
>> in
>>     
>>>> reading or writing back.
>>>>
>>>> Thanks
>>>> Blesson Paul
>>>> --- Blesson Paul <ble...@ya...> wrote:
>>>>
>>>>     
>>>>         
>>>>> Hi,
>>>>>
>>>>> I have an issue with apache and HTML template.
>>>>>       
>>>>>           
>>>> When
>>>>     
>>>>         
>>>>> HTML::Tempate->param process files, it add extra
>>>>> charecters in between UTF charecters. It won't
>>>>> happen
>>>>> if I execute from command line. 
>>>>>
>>>>> I belive there is some thing in the apache env
>>>>>       
>>>>>           
>>>> which
>>>>     
>>>>         
>>>>> causes this issue. In most of the time,
>>>>>           
>> control-C
>>     
>>>>> charecter is added. 
>>>>>
>>>>>
>>>>> Did anybody faced the same issue.
>>>>>
>>>>> Thanks
>>>>> Blesson Paul
>>>>>
>>>>>
>>>>>        
>>>>>
>>>>>       
>>>>>           
> ____________________________________________________________________________________Ready
>   
>>>   
>>>       
>>>>> for the edge of your seat? 
>>>>> Check out tonight's top picks on Yahoo! TV. 
>>>>> http://tv.yahoo.com/
>>>>>
>>>>>
>>>>>       
>>>>>           
> -------------------------------------------------------------------------
>   
>>>   
>>>       
>>>>> This SF.net email is sponsored by DB2 Express
>>>>> Download DB2 Express C - the FREE version of DB2
>>>>> express and take
>>>>> control of your XML. No limits. Just data. Click
>>>>>       
>>>>>           
>>>> to
>>>>     
>>>>         
>>>>> get it now.
>>>>> http://sourceforge.net/powerbar/db2/
>>>>> _______________________________________________
>>>>> Html-template-users mailing list
>>>>> Htm...@li...
>>>>>
>>>>>       
>>>>>           
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   
>>>   
>>>       
>>>>        
>>>>
>>>>     
>>>>         
> ____________________________________________________________________________________
>   
>>>   
>>>       
>>>> Be a better Globetrotter. Get better travel
>>>>         
>> answers
>>     
>>>> from someone who knows. Yahoo! Answers - Check it
>>>> out.
>>>>
>>>>     
>>>>         
> http://answers.yahoo.com/dir/?link=list&sid=396545469
>   
>>>   
>>>
>>>
>>>
>>>        
>>>
>>>       
> ____________________________________________________________________________________
>   
>>> Yahoo! oneSearch: Finally, mobile search 
>>> that gives answers, not web links. 
>>>
>>>       
> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
>   
>>>       
> -------------------------------------------------------------------------
>   
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2
>>>       
>> express and take
>>     
>>> control of your XML. No limits. Just data. Click
>>>       
>> to get it now.
>>     
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Html-template-users mailing list
>>> Htm...@li...
>>>
>>>       
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   
>>>   
>>>       
>
>
>
>       ____________________________________________________________________________________
> Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 
>
>
>   

Re: [htmltmpl] apache and html template

[Blesson P. <ble...@ya...>]

Hi,

I have an issue with Polish character ś. This
charecter is corrupted when it is outputed through
HTML::Template->output(). 

Only this charecter is causing the issue. Rest of them
are fine. Is there any solution to solve this 

Thanks
blesson Paul
--- Mathew Robertson
<mat...@ne...> wrote:

> Hi Paul,
> 
> Which version of Perl are you using?   I have used
> 5.6.x and 5.8.x and
> found that 5.8.3 or better was required for bug-less
> operation.
> 
> Mathew Robertson
> 
> Blesson Paul wrote:
> > My problem is same as this one
> >
>
http://www.template-toolkit.org/pipermail/templates/2003-March/004314.html
> >
> > Any fix for this.
> >
> > Thanks
> > Blesson Paul
> > --- Blesson Paul <ble...@ya...> wrote:
> >
> >   
> >> Just add to that, If I didn't do Template->param,
> >> there is no issue. That means there is no issue
> in
> >> reading or writing back.
> >>
> >> Thanks
> >> Blesson Paul
> >> --- Blesson Paul <ble...@ya...> wrote:
> >>
> >>     
> >>> Hi,
> >>>
> >>> I have an issue with apache and HTML template.
> >>>       
> >> When
> >>     
> >>> HTML::Tempate->param process files, it add extra
> >>> charecters in between UTF charecters. It won't
> >>> happen
> >>> if I execute from command line. 
> >>>
> >>> I belive there is some thing in the apache env
> >>>       
> >> which
> >>     
> >>> causes this issue. In most of the time,
> control-C
> >>> charecter is added. 
> >>>
> >>>
> >>> Did anybody faced the same issue.
> >>>
> >>> Thanks
> >>> Blesson Paul
> >>>
> >>>
> >>>        
> >>>
> >>>       
> >
>
____________________________________________________________________________________Ready
> >   
> >>> for the edge of your seat? 
> >>> Check out tonight's top picks on Yahoo! TV. 
> >>> http://tv.yahoo.com/
> >>>
> >>>
> >>>       
> >
>
-------------------------------------------------------------------------
> >   
> >>> This SF.net email is sponsored by DB2 Express
> >>> Download DB2 Express C - the FREE version of DB2
> >>> express and take
> >>> control of your XML. No limits. Just data. Click
> >>>       
> >> to
> >>     
> >>> get it now.
> >>> http://sourceforge.net/powerbar/db2/
> >>> _______________________________________________
> >>> Html-template-users mailing list
> >>> Htm...@li...
> >>>
> >>>       
> >
>
https://lists.sourceforge.net/lists/listinfo/html-template-users
> >   
> >>
> >>        
> >>
> >>     
> >
>
____________________________________________________________________________________
> >   
> >> Be a better Globetrotter. Get better travel
> answers
> >> from someone who knows. Yahoo! Answers - Check it
> >> out.
> >>
> >>     
> >
>
http://answers.yahoo.com/dir/?link=list&sid=396545469
> >   
> >
> >
> >
> >        
> >
>
____________________________________________________________________________________
> > Yahoo! oneSearch: Finally, mobile search 
> > that gives answers, not web links. 
> >
>
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
> >
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> express and take
> > control of your XML. No limits. Just data. Click
> to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Html-template-users mailing list
> > Htm...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/html-template-users
> >   
> 



      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

Re: [htmltmpl] Bug in param() when odd reference passed in?

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

Hi Brad,
> I think I've found a small bug in param().  It's not a killer for me, but
> I thought I'd mention it.  Here's an example that triggers the behavior
> I'm seeing (I'm using HTML::Template version 2.8, but I think 2.9 would
> behave this way, too):
>
> perl -MHTML::Template -wle'$o="<TMPL_VAR
> x>";$t=HTML::Template->new(scalarref=>\$o);$t->param(x=>\{});print
> $t->output()'
> Can't call method "isa" on unblessed reference at
> /opt/perl/lib/site_perl/5.8.8/HTML/Template.pm line 2527.
>
> Line 2527 looks like this:
>
>  if (defined($value_type) and length($value_type) and ($value_type eq
> 'ARRAY' or ((ref($value) !~ /^(CODE)|(HASH)|(SCALAR)$/) and
> $value->isa('ARRAY')))) {
>
> What's happening is that $value_type is "REF", so it's getting past all
> the other checks and calling isa(), giving the error.
It should really be:   UNIVERSAL::isa($value,'ARRAY')
rather than:             $value->isa('ARRAY')

>
> First off, I think /^(CODE)|(HASH)|(SCALAR)$/) should instead be
> /^(CODE|HASH|SCALAR)$/).  But if I'm following the logic correctly,
> I think it should be /^(CODE|GLOB|HASH|LVALUE|REF|SCALAR)$/).
>
> So I think the fix is to change that line to the following:
>
>  if (defined($value_type) and length($value_type) and ($value_type eq
> 'ARRAY' or (($value_type !~ /^(CODE|GLOB|HASH|LVALUE|REF|SCALAR)$/)
> and $value->isa('ARRAY')))) {
>
> (Note that I also replaced ref($value) with $value_type.)
>
> When I rerun the above one-liner with this change, the output is
>
> REF(0x14b1d8)
>
> which is consistent with what you currently get if you pass, say, a
> hash reference, e.g.,
>
> perl -MHTML::Template -wle'$o="<TMPL_VAR
> x>";$t=HTML::Template->new(scalarref=>\$o);$t->param(x=>{});print
> $t->output()'
> HASH(0x124170)
>
> I hope that all makes sense.  I have *not* run this through the
> tests, though, so I don't know if that will show up flaws in my
> understanding.
That all depends on your point of view.... :-)

H::T doesn't use hash's as values to params, so one would expect an
error (although it doesn't, it simply prints the hex code of the address
of the hash).   I would argue that this behaviour "isn't good template
engine behaviour" -> H::T should probably croak since that param type
isn't supported.

However, some people have extended H::T to support "structure-esque"
template variables,  eg:  name.fist, name.last.    If your version of
H::T supports this, then one could argue that passing in a hash (or hash
ref), should auto-vivify the template variables. For example:

  $ht->param( name => { first => "fred", last => "flinstone"} );

auto-vivifies:    "name", "name.first", "name.last"

One could also justify wanting the ability to pass in a sub-ref, thus
expecting that <TMPL_VAR sub { ... }> would execute the sub-ref.

cheers,
Mathew Robertson

Re: [htmltmpl] Odd slowdown in HTML::Template with INCL and LOOP

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

>> When a TMPL_LOOP is encountered, H::T needs to create (for want of a
>> better description) a child context, that contains only the template
>> variables for the child.  Each child context is effectively a new
>> H::T object, so that the very top H::T object accumulates the output
>> from each child.
>
> OK, that makes sense.  I don't understand why DProf is showing more
> BEGIN blocks in this case though.  As far as I could see from a scan
> of the code it should be just instantiating ->new objects rather than
> re-evalling, so I don't understand where this is coming from.
My experience with DProf has been good and bad; I find the output a
little confusing.... Usually "print nanosecond-timer" gives me the good oil.
>
>> By removing the LOOP, you are effectively completely avoiding the
>> child context thus saving quite a significant amount of processing.
>
> Ah!  Even if the child process is used to process a loop of 20 items,
> if the parent context is large, the whole context is copied non-lazily
> to the child?
Depends if "global_vars" is set; although, that option doesn't
immediately cause too much of a slow down.
>
> We have tried running the template output with the largest context
> object (dictionary for localisation) turned off, without noticing
> any impact on the pathological case.
did you mean "largest object 'associate'd with H::T"?

In any case, most of the code is O(n) for template size and O(1) or
similar for param-value lookups.
>
>> If you are looking for performance increases, you should start simply
>> by printing a hi-res time from various points within "output()".  I
>> have done this previously and found that I was able to find a
>> dramatic increase in performance, just by removing foreach() loops. **
>
> That's a possibility, though I think loops are fairly basic
> functionality that I'd like not to have to prune from template code...
Past programming experience tells me that "for { for { ... }}" is
O(n^2)... so that is always the first thing I look for.  H::T has this
case at the very start of the output() code block -> so its a good
candidate for profiling.
>
>> regards,
>> Mathew Robertson
>>
>> ** If you interested, I can send you a patch which ("works for me")
>> speed's up the template-variable symbol resolution.  This patch has
>> achieved close to 20x speed up under some circumstances. Most
>> templates are speed up by about 1.5x.
>
> Shiny!  I'd be interested to take a look,
No sweat.  This replaces the "associate magic" code block lines 2658 to
2686 (H::T 2.9, 2.8 is similar):

  # support the associate magic, searching for undefined params and
  # attempting to fill them from the associated objects.
  if (scalar(@{$options->{associate}})) {
    my @undef_params;
    foreach my $param (keys %{$self->{param_map}}) {
      next if (defined $self->param($param));
      push @undef_params, $param;
    }
    if (scalar(@undef_params)) {
      my $value;
      # if case sensitive mode or no CGI objects, we can use the fast path
      if ($options->{case_sensitive} or (grep { !/^1/ } map {
UNIVERSAL::isa($_,'HTML::Template') } @{$options->{associate}}) == 0) {
        foreach my $param (@undef_params) {
          foreach my $associated_object (reverse @{$options->{associate}}) {
            $value = $associated_object->param($param);
            next unless (defined $value);
            $self->param($param, scalar $value);
            last;
          }
        }
      } else {
        my %case_map;
        foreach my $associated_object (@{$options->{associate}}) {
          map { $case_map{$associated_object}{lc($_)} = $_ }
$associated_object->param();
        }
        my $associated_param;
        foreach my $param (@undef_params) {
          foreach my $associated_object (reverse @{$options->{associate}}) {
            $associated_param = $case_map{$associated_object}{$param};
            next unless (defined $associated_param);
            $value = $associated_object->param($associated_param);
            next unless (defined $value);
            $self->param($param, scalar $value);
            last;
          }
        }
      }
    }
  }

You probably want to do a timing check using the old code vs this new
code - just to ensure that it isn't making the problem worse.

cheers,
Mathew

[htmltmpl] Bug in param() when odd reference passed in?

[Brad B. <bm...@ma...>]

Hello all,

I think I've found a small bug in param().  It's not a killer for me, but
I thought I'd mention it.  Here's an example that triggers the behavior
I'm seeing (I'm using HTML::Template version 2.8, but I think 2.9 would
behave this way, too):

perl -MHTML::Template -wle'$o="<TMPL_VAR
x>";$t=HTML::Template->new(scalarref=>\$o);$t->param(x=>\{});print
$t->output()'
Can't call method "isa" on unblessed reference at
/opt/perl/lib/site_perl/5.8.8/HTML/Template.pm line 2527.

Line 2527 looks like this:

 if (defined($value_type) and length($value_type) and ($value_type eq
'ARRAY' or ((ref($value) !~ /^(CODE)|(HASH)|(SCALAR)$/) and
$value->isa('ARRAY')))) {

What's happening is that $value_type is "REF", so it's getting past all
the other checks and calling isa(), giving the error.

First off, I think /^(CODE)|(HASH)|(SCALAR)$/) should instead be
/^(CODE|HASH|SCALAR)$/).  But if I'm following the logic correctly,
I think it should be /^(CODE|GLOB|HASH|LVALUE|REF|SCALAR)$/).

So I think the fix is to change that line to the following:

 if (defined($value_type) and length($value_type) and ($value_type eq
'ARRAY' or (($value_type !~ /^(CODE|GLOB|HASH|LVALUE|REF|SCALAR)$/) and
$value->isa('ARRAY')))) {

(Note that I also replaced ref($value) with $value_type.)

When I rerun the above one-liner with this change, the output is

REF(0x14b1d8)

which is consistent with what you currently get if you pass, say, a
hash reference, e.g.,

perl -MHTML::Template -wle'$o="<TMPL_VAR
x>";$t=HTML::Template->new(scalarref=>\$o);$t->param(x=>{});print
$t->output()'
HASH(0x124170)

I hope that all makes sense.  I have *not* run this through the
tests, though, so I don't know if that will show up flaws in my
understanding.

Thanks,

-- Brad

Re: [htmltmpl] Odd slowdown in HTML::Template with INCL and LOOP

[Hakim C. <hak...@da...>]

Mathew Robertson ha scritto:
> Hi Hakim,
> 
> I think you might be over analysing the problem. :-)

Heh, that is possible :-)

> 
> When a TMPL_LOOP is encountered, H::T needs to create (for want of a 
> better description) a child context, that contains only the template 
> variables for the child.  Each child context is effectively a new H::T 
> object, so that the very top H::T object accumulates the output from 
> each child.

OK, that makes sense.  I don't understand why DProf is showing more
BEGIN blocks in this case though.  As far as I could see from a scan
of the code it should be just instantiating ->new objects rather than
re-evalling, so I don't understand where this is coming from.

> By removing the LOOP, you are effectively completely avoiding the child 
> context thus saving quite a significant amount of processing.

Ah!  Even if the child process is used to process a loop of 20 items,
if the parent context is large, the whole context is copied non-lazily
to the child?

We have tried running the template output with the largest context
object (dictionary for localisation) turned off, without noticing
any impact on the pathological case.

> If you are looking for performance increases, you should start simply by 
> printing a hi-res time from various points within "output()".  I have 
> done this previously and found that I was able to find a dramatic 
> increase in performance, just by removing foreach() loops. **

That's a possibility, though I think loops are fairly basic
functionality that I'd like not to have to prune from template code...

> regards,
> Mathew Robertson
> 
> ** If you interested, I can send you a patch which ("works for me") 
> speed's up the template-variable symbol resolution.  This patch has 
> achieved close to 20x speed up under some circumstances. Most templates 
> are speed up by about 1.5x.

Shiny!  I'd be interested to take a look,

Thanks and regards,
Hakim


> 
> 
> Hakim Cassimally wrote:
>> Hakim Cassimally wrote:
>>   
>>> Hi,
>>>
>>> We're having an "interesting" problem with a significant slowdown in
>>> processing of some HTML::Template templates.
>>>     
>>
>> The current suspicion, after HTML bod and $boss worked on this,
>> by a process of elimination is that the problem is when the same
>> data structure is used twice in the same ->output() call.
>>
>> So, in some cases, the loop "REGION" below, was used twice in
>> two separate TMPL_LOOP cases.  This seems to add as much as
>> 0.5 seconds every time the parameter is reused.
>>
>> The workaround seems to be to clone the data structure and
>> create two separate parameters, which seems very wrong.  Has
>> anyone else experienced this?  (It might be a feature of our
>> framework code rather than H::T, I'll work on the minimal test
>> case on Friday after a release...)
>>
>> Cheerio,
>> Hakim
>>
>>   
>>> We are using:
>>>   - using H::T 2.8 and 2.9
>>>   - an house framework that feeds params from a CGI object to H::T
>>>   - CGI 2.81 and 3.15
>>>   - Perl 5.8.0 and 5.8.4
>>>
>>> If the following conditions hold:
>>>
>>>   - template X is <TMPL_INCL>uded
>>>   - the parameter "region" is set (for <TMPL_LOOP NAME="REGION">)
>>>
>>> then processing time for the template is approx 1 second longer.
>>>
>>> However
>>>
>>>   - if either the TMPL_INCL or the TMPL_LOOPs are commented, processing
>>>     time is reduced
>>>   - the TMPL_INCL does *not* refer to the TMPL_LOOP, and neither does the
>>>     one template it in turn includes.
>>>
>>> The DProf runs include the following (with some entries for BEGIN on
>>> inhouse modules removed) :
>>>
>>> --------------- without including TMPL_LOOP
>>>
>>> $ dprofpp -rI 
>>> province_noprov.out
>>> Total Elapsed Time = 1.346560 Seconds
>>>           Real Time = 1.346560 Seconds
>>> Inclusive Times
>>> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>>>   65.7   0.030  0.885      5   0.0060 0.1770  main::BEGIN
>>>   43.8   0.008  0.590      1   0.0083 0.5899  Our::Application::pageOutput
>>>   43.8   0.000  0.590      1   0.0000 0.5897 
>>> Our::Application::printPageOutput
>>>   9.43   0.050  0.127     78   0.0006 0.0016  HTML::Template::BEGIN
>>>   8.69   0.000  0.117    539   0.0000 0.0002  JSON::Parser::value
>>>   8.24   0.120  0.111   9267   0.0000 0.0000  HTML::Template::param
>>>   7.28   0.000  0.098      2   0.0000 0.0488  HTML::Template::_init
>>>
>>> --------------- with the TMPL_LOOP
>>>
>>> $ dprofpp -rI 
>>> province_prov.out
>>> Total Elapsed Time = 2.443450 Seconds
>>>           Real Time = 2.443450 Seconds
>>> Inclusive Times
>>> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>>>   109.   1.149  2.676    387   0.0030 0.0069  HTML::Template::BEGIN
>>>   76.8   0.000  1.877      1   0.0000 1.8765 
>>> Our::Application::printPageOutput
>>>   76.4   0.027  1.867      1   0.0275 1.8668  Our::Application::pageOutput
>>>   55.5   0.010  1.356      8   0.0012 0.1696  HTML::Template::LOOP::output
>>>   34.9   0.020  0.853      5   0.0040 0.1705  main::BEGIN
>>>   10.4   0.300  0.256  28736   0.0000 0.0000  HTML::Template::param
>>>
>>> e.g. the odd things include
>>>
>>> - "HTML::Template::BEGIN" is called a large number of times.  I don't
>>>    see that many BEGIN { } or 'use' blocks in the H::T code, nor do I
>>> understand why they would be called because of a TMPL_INCL
>>>
>>> - HTML::Template::LOOP::output takes proportionally much longer.
>>>
>>> I'm sorry that this isn't a minimal test case - I'm working with our
>>> HTML editor to try to identify what it is!  But if anyone has any
>>> suggestions on where to start trying to debug this, I'd be interested,
>>> and grateful, to see what you suggest.
>>>
>>> Regards,
>>>
>>> Hakim (osfameron)
>>>     
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Html-template-users mailing list
>> Htm...@li...
>> https://lists.sourceforge.net/lists/listinfo/html-template-users
>>   

Re: [htmltmpl] Odd slowdown in HTML::Template with INCL and LOOP

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

Hi Hakim,

I think you might be over analysing the problem. :-)

When a TMPL_LOOP is encountered, H::T needs to create (for want of a
better description) a child context, that contains only the template
variables for the child.  Each child context is effectively a new H::T
object, so that the very top H::T object accumulates the output from
each child.

By removing the LOOP, you are effectively completely avoiding the child
context thus saving quite a significant amount of processing.

If you are looking for performance increases, you should start simply by
printing a hi-res time from various points within "output()".  I have
done this previously and found that I was able to find a dramatic
increase in performance, just by removing foreach() loops. **

regards,
Mathew Robertson

** If you interested, I can send you a patch which ("works for me")
speed's up the template-variable symbol resolution.  This patch has
achieved close to 20x speed up under some circumstances. Most templates
are speed up by about 1.5x.


Hakim Cassimally wrote:
> Hakim Cassimally wrote:
>   
>> Hi,
>>
>> We're having an "interesting" problem with a significant slowdown in
>> processing of some HTML::Template templates.
>>     
>
> The current suspicion, after HTML bod and $boss worked on this,
> by a process of elimination is that the problem is when the same
> data structure is used twice in the same ->output() call.
>
> So, in some cases, the loop "REGION" below, was used twice in
> two separate TMPL_LOOP cases.  This seems to add as much as
> 0.5 seconds every time the parameter is reused.
>
> The workaround seems to be to clone the data structure and
> create two separate parameters, which seems very wrong.  Has
> anyone else experienced this?  (It might be a feature of our
> framework code rather than H::T, I'll work on the minimal test
> case on Friday after a release...)
>
> Cheerio,
> Hakim
>
>   
>> We are using:
>>   - using H::T 2.8 and 2.9
>>   - an house framework that feeds params from a CGI object to H::T
>>   - CGI 2.81 and 3.15
>>   - Perl 5.8.0 and 5.8.4
>>
>> If the following conditions hold:
>>
>>   - template X is <TMPL_INCL>uded
>>   - the parameter "region" is set (for <TMPL_LOOP NAME="REGION">)
>>
>> then processing time for the template is approx 1 second longer.
>>
>> However
>>
>>   - if either the TMPL_INCL or the TMPL_LOOPs are commented, processing
>>     time is reduced
>>   - the TMPL_INCL does *not* refer to the TMPL_LOOP, and neither does the
>>     one template it in turn includes.
>>
>> The DProf runs include the following (with some entries for BEGIN on
>> inhouse modules removed) :
>>
>> --------------- without including TMPL_LOOP
>>
>> $ dprofpp -rI 
>> province_noprov.out
>> Total Elapsed Time = 1.346560 Seconds
>>           Real Time = 1.346560 Seconds
>> Inclusive Times
>> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>>   65.7   0.030  0.885      5   0.0060 0.1770  main::BEGIN
>>   43.8   0.008  0.590      1   0.0083 0.5899  Our::Application::pageOutput
>>   43.8   0.000  0.590      1   0.0000 0.5897 
>> Our::Application::printPageOutput
>>   9.43   0.050  0.127     78   0.0006 0.0016  HTML::Template::BEGIN
>>   8.69   0.000  0.117    539   0.0000 0.0002  JSON::Parser::value
>>   8.24   0.120  0.111   9267   0.0000 0.0000  HTML::Template::param
>>   7.28   0.000  0.098      2   0.0000 0.0488  HTML::Template::_init
>>
>> --------------- with the TMPL_LOOP
>>
>> $ dprofpp -rI 
>> province_prov.out
>> Total Elapsed Time = 2.443450 Seconds
>>           Real Time = 2.443450 Seconds
>> Inclusive Times
>> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>>   109.   1.149  2.676    387   0.0030 0.0069  HTML::Template::BEGIN
>>   76.8   0.000  1.877      1   0.0000 1.8765 
>> Our::Application::printPageOutput
>>   76.4   0.027  1.867      1   0.0275 1.8668  Our::Application::pageOutput
>>   55.5   0.010  1.356      8   0.0012 0.1696  HTML::Template::LOOP::output
>>   34.9   0.020  0.853      5   0.0040 0.1705  main::BEGIN
>>   10.4   0.300  0.256  28736   0.0000 0.0000  HTML::Template::param
>>
>> e.g. the odd things include
>>
>> - "HTML::Template::BEGIN" is called a large number of times.  I don't
>>    see that many BEGIN { } or 'use' blocks in the H::T code, nor do I
>> understand why they would be called because of a TMPL_INCL
>>
>> - HTML::Template::LOOP::output takes proportionally much longer.
>>
>> I'm sorry that this isn't a minimal test case - I'm working with our
>> HTML editor to try to identify what it is!  But if anyone has any
>> suggestions on where to start trying to debug this, I'd be interested,
>> and grateful, to see what you suggest.
>>
>> Regards,
>>
>> Hakim (osfameron)
>>     
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   

Re: [htmltmpl] Odd slowdown in HTML::Template with INCL and LOOP

[Hakim C. <hak...@da...>]

Hakim Cassimally wrote:
> Hi,
> 
> We're having an "interesting" problem with a significant slowdown in
> processing of some HTML::Template templates.

The current suspicion, after HTML bod and $boss worked on this,
by a process of elimination is that the problem is when the same
data structure is used twice in the same ->output() call.

So, in some cases, the loop "REGION" below, was used twice in
two separate TMPL_LOOP cases.  This seems to add as much as
0.5 seconds every time the parameter is reused.

The workaround seems to be to clone the data structure and
create two separate parameters, which seems very wrong.  Has
anyone else experienced this?  (It might be a feature of our
framework code rather than H::T, I'll work on the minimal test
case on Friday after a release...)

Cheerio,
Hakim

> We are using:
>   - using H::T 2.8 and 2.9
>   - an house framework that feeds params from a CGI object to H::T
>   - CGI 2.81 and 3.15
>   - Perl 5.8.0 and 5.8.4
> 
> If the following conditions hold:
> 
>   - template X is <TMPL_INCL>uded
>   - the parameter "region" is set (for <TMPL_LOOP NAME="REGION">)
> 
> then processing time for the template is approx 1 second longer.
> 
> However
> 
>   - if either the TMPL_INCL or the TMPL_LOOPs are commented, processing
>     time is reduced
>   - the TMPL_INCL does *not* refer to the TMPL_LOOP, and neither does the
>     one template it in turn includes.
> 
> The DProf runs include the following (with some entries for BEGIN on
> inhouse modules removed) :
> 
> --------------- without including TMPL_LOOP
> 
> $ dprofpp -rI 
> province_noprov.out
> Total Elapsed Time = 1.346560 Seconds
>           Real Time = 1.346560 Seconds
> Inclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>   65.7   0.030  0.885      5   0.0060 0.1770  main::BEGIN
>   43.8   0.008  0.590      1   0.0083 0.5899  Our::Application::pageOutput
>   43.8   0.000  0.590      1   0.0000 0.5897 
> Our::Application::printPageOutput
>   9.43   0.050  0.127     78   0.0006 0.0016  HTML::Template::BEGIN
>   8.69   0.000  0.117    539   0.0000 0.0002  JSON::Parser::value
>   8.24   0.120  0.111   9267   0.0000 0.0000  HTML::Template::param
>   7.28   0.000  0.098      2   0.0000 0.0488  HTML::Template::_init
> 
> --------------- with the TMPL_LOOP
> 
> $ dprofpp -rI 
> province_prov.out
> Total Elapsed Time = 2.443450 Seconds
>           Real Time = 2.443450 Seconds
> Inclusive Times
> %Time ExclSec CumulS #Calls sec/call Csec/c  Name
>   109.   1.149  2.676    387   0.0030 0.0069  HTML::Template::BEGIN
>   76.8   0.000  1.877      1   0.0000 1.8765 
> Our::Application::printPageOutput
>   76.4   0.027  1.867      1   0.0275 1.8668  Our::Application::pageOutput
>   55.5   0.010  1.356      8   0.0012 0.1696  HTML::Template::LOOP::output
>   34.9   0.020  0.853      5   0.0040 0.1705  main::BEGIN
>   10.4   0.300  0.256  28736   0.0000 0.0000  HTML::Template::param
> 
> e.g. the odd things include
> 
> - "HTML::Template::BEGIN" is called a large number of times.  I don't
>    see that many BEGIN { } or 'use' blocks in the H::T code, nor do I
> understand why they would be called because of a TMPL_INCL
> 
> - HTML::Template::LOOP::output takes proportionally much longer.
> 
> I'm sorry that this isn't a minimal test case - I'm working with our
> HTML editor to try to identify what it is!  But if anyone has any
> suggestions on where to start trying to debug this, I'd be interested,
> and grateful, to see what you suggest.
> 
> Regards,
> 
> Hakim (osfameron)

[htmltmpl] Odd slowdown in HTML::Template with INCL and LOOP

[Hakim C. <hak...@da...>]

Hi,

We're having an "interesting" problem with a significant slowdown in
processing of some HTML::Template templates.

We are using:
  - using H::T 2.8 and 2.9
  - an house framework that feeds params from a CGI object to H::T
  - CGI 2.81 and 3.15
  - Perl 5.8.0 and 5.8.4

If the following conditions hold:

  - template X is <TMPL_INCL>uded
  - the parameter "region" is set (for <TMPL_LOOP NAME="REGION">)

then processing time for the template is approx 1 second longer.

However

  - if either the TMPL_INCL or the TMPL_LOOPs are commented, processing
    time is reduced
  - the TMPL_INCL does *not* refer to the TMPL_LOOP, and neither does the
    one template it in turn includes.

The DProf runs include the following (with some entries for BEGIN on
inhouse modules removed) :

--------------- without including TMPL_LOOP

super@adamo102:/SEVA/dada.net/beta2/cgi-bin/sn_test$ dprofpp -rI 
province_noprov.out
Total Elapsed Time = 1.346560 Seconds
          Real Time = 1.346560 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
  65.7   0.030  0.885      5   0.0060 0.1770  main::BEGIN
  43.8   0.008  0.590      1   0.0083 0.5899  Our::Application::pageOutput
  43.8   0.000  0.590      1   0.0000 0.5897 
Our::Application::printPageOutput
  9.43   0.050  0.127     78   0.0006 0.0016  HTML::Template::BEGIN
  8.69   0.000  0.117    539   0.0000 0.0002  JSON::Parser::value
  8.24   0.120  0.111   9267   0.0000 0.0000  HTML::Template::param
  7.28   0.000  0.098      2   0.0000 0.0488  HTML::Template::_init

--------------- with the TMPL_LOOP

super@adamo102:/SEVA/dada.net/beta2/cgi-bin/sn_test$ dprofpp -rI 
province_prov.out
Total Elapsed Time = 2.443450 Seconds
          Real Time = 2.443450 Seconds
Inclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
  109.   1.149  2.676    387   0.0030 0.0069  HTML::Template::BEGIN
  76.8   0.000  1.877      1   0.0000 1.8765 
Our::Application::printPageOutput
  76.4   0.027  1.867      1   0.0275 1.8668  Our::Application::pageOutput
  55.5   0.010  1.356      8   0.0012 0.1696  HTML::Template::LOOP::output
  34.9   0.020  0.853      5   0.0040 0.1705  main::BEGIN
  10.4   0.300  0.256  28736   0.0000 0.0000  HTML::Template::param

e.g. the odd things include

- "HTML::Template::BEGIN" is called a large number of times.  I don't
   see that many BEGIN { } or 'use' blocks in the H::T code, nor do I
understand why they would be called because of a TMPL_INCL

- HTML::Template::LOOP::output takes proportionally much longer.

I'm sorry that this isn't a minimal test case - I'm working with our
HTML editor to try to identify what it is!  But if anyone has any
suggestions on where to start trying to debug this, I'd be interested,
and grateful, to see what you suggest.

Regards,

Hakim (osfameron)

Re: [htmltmpl] problem: Not an ARRAY reference in Expr.pm

[Marcin G. <mg...@fo...>]

Hi Matthew

On Tuesday of June 26 2007, you wrote:
> Have you tried enabling the file_cache only (ie not the memory cache)?
> It may help nail whether the problem is with H::T or something else.

The HTML::Template::Expr says (in caveats section):

"The module won't work with HTML::Template's file_cache or shared_cache modes, 
but normal memory caching should work. I hope to address this is a future 
version."

Is above still valid or something got fixed and I can use file cache?

greetings
-- 
Marcin Gryszkalis, PGP 0x9F183FA3 
jabber jid:mg...@fo..., gg:2532994
http://the.fork.pl

Re: [htmltmpl] problem: Not an ARRAY reference in Expr.pm

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

Hi Marcin,

This has been sitting in my inbox for a while, but I didn't really have
an ideas.

Have you tried enabling the file_cache only (ie not the memory cache)? 
It may help nail whether the problem is with H::T or something else.

regards,
Mathew Robertson

Marcin Gryszkalis wrote:
> On Friday of June 1 2007, you wrote:
>   
>> Did you ever resolve this?   After looking at the problem again, I
>> suspect that some variable was being set/used incorrectly, ie: a scalar
>> was being set on the param, but trying to be used in a loop -> or more
>> specifically vice versa inside an EXPR...
>>     
>
> Unfortunately - no, the only way to solve it is to turn off cache, I use 
> following options:
>
> my %default_options = (
>     die_on_bad_params => 0,
>     search_path_on_include => 1,
>     loop_context_vars => 1,
>     global_vars => 1,
>     strict => 1,
>     cache => 1,
> );
>
>
> after I set cache=>0 the errors don't show anymore (with cache on they show 
> randomly, like once every 10-20 calls - with the same almost static (just 
> several includes) page)...
>
> Any help or directions how to debug this will be appreciated.
> greetings
>   

Re: [htmltmpl] apache and html template

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

Hi Paul,

Which version of Perl are you using?   I have used 5.6.x and 5.8.x and
found that 5.8.3 or better was required for bug-less operation.

Mathew Robertson

Blesson Paul wrote:
> My problem is same as this one
> http://www.template-toolkit.org/pipermail/templates/2003-March/004314.html
>
> Any fix for this.
>
> Thanks
> Blesson Paul
> --- Blesson Paul <ble...@ya...> wrote:
>
>   
>> Just add to that, If I didn't do Template->param,
>> there is no issue. That means there is no issue in
>> reading or writing back.
>>
>> Thanks
>> Blesson Paul
>> --- Blesson Paul <ble...@ya...> wrote:
>>
>>     
>>> Hi,
>>>
>>> I have an issue with apache and HTML template.
>>>       
>> When
>>     
>>> HTML::Tempate->param process files, it add extra
>>> charecters in between UTF charecters. It won't
>>> happen
>>> if I execute from command line. 
>>>
>>> I belive there is some thing in the apache env
>>>       
>> which
>>     
>>> causes this issue. In most of the time, control-C
>>> charecter is added. 
>>>
>>>
>>> Did anybody faced the same issue.
>>>
>>> Thanks
>>> Blesson Paul
>>>
>>>
>>>        
>>>
>>>       
> ____________________________________________________________________________________Ready
>   
>>> for the edge of your seat? 
>>> Check out tonight's top picks on Yahoo! TV. 
>>> http://tv.yahoo.com/
>>>
>>>
>>>       
> -------------------------------------------------------------------------
>   
>>> This SF.net email is sponsored by DB2 Express
>>> Download DB2 Express C - the FREE version of DB2
>>> express and take
>>> control of your XML. No limits. Just data. Click
>>>       
>> to
>>     
>>> get it now.
>>> http://sourceforge.net/powerbar/db2/
>>> _______________________________________________
>>> Html-template-users mailing list
>>> Htm...@li...
>>>
>>>       
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   
>>
>>        
>>
>>     
> ____________________________________________________________________________________
>   
>> Be a better Globetrotter. Get better travel answers
>> from someone who knows. Yahoo! Answers - Check it
>> out.
>>
>>     
> http://answers.yahoo.com/dir/?link=list&sid=396545469
>   
>
>
>
>        
> ____________________________________________________________________________________
> Yahoo! oneSearch: Finally, mobile search 
> that gives answers, not web links. 
> http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>   

Re: [htmltmpl] apache and html template

[Blesson P. <ble...@ya...>]

My problem is same as this one
http://www.template-toolkit.org/pipermail/templates/2003-March/004314.html

Any fix for this.

Thanks
Blesson Paul
--- Blesson Paul <ble...@ya...> wrote:

> Just add to that, If I didn't do Template->param,
> there is no issue. That means there is no issue in
> reading or writing back.
> 
> Thanks
> Blesson Paul
> --- Blesson Paul <ble...@ya...> wrote:
> 
> > Hi,
> > 
> > I have an issue with apache and HTML template.
> When
> > HTML::Tempate->param process files, it add extra
> > charecters in between UTF charecters. It won't
> > happen
> > if I execute from command line. 
> > 
> > I belive there is some thing in the apache env
> which
> > causes this issue. In most of the time, control-C
> > charecter is added. 
> > 
> > 
> > Did anybody faced the same issue.
> > 
> > Thanks
> > Blesson Paul
> > 
> > 
> >        
> >
>
____________________________________________________________________________________Ready
> > for the edge of your seat? 
> > Check out tonight's top picks on Yahoo! TV. 
> > http://tv.yahoo.com/
> > 
> >
>
-------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2
> > express and take
> > control of your XML. No limits. Just data. Click
> to
> > get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Html-template-users mailing list
> > Htm...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/html-template-users
> > 
> 
> 
> 
>        
>
____________________________________________________________________________________
> Be a better Globetrotter. Get better travel answers
> from someone who knows. Yahoo! Answers - Check it
> out.
>
http://answers.yahoo.com/dir/?link=list&sid=396545469
> 



       
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search 
that gives answers, not web links. 
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC