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

Re: [htmltmpl] (no subject) [Patch]

[Emanuele Z. <em...@li...>]

There was an error in the new test provided, sorry.
Here is the correct version.

Cheers,
Emanuele.

Re: [htmltmpl] (no subject) [Patch]

[Emanuele Z. <em...@li...>]

> -----Original Message-----
> From: htm...@li...=20
> [mailto:htm...@li...] On=20
> Behalf Of Sam Tregar
> Sent: Monday, July 11, 2005 8:00 PM
> To: Emanuele Zeppieri
> Cc: htm...@li...
> Subject: Re: [htmltmpl] (no subject)
>=20
>=20
> On Mon, 11 Jul 2005, Emanuele Zeppieri wrote:
>=20
> > Well, I'm probably missing something (or everything), but=20
> it seems to me
> > that the following compiled code layout could solve the problem:
> >=20
> > 	JUMP to A IF false
> > 	... # first true instruction
> > 	...
> > 	... # last true instruction
> > 	JUMP TO B
> > A: 	... # first false instruction
> > 	...
> > 	... # last false instruction
> > B:	... # normal execution after the IF/ELSE, if any...
>=20
> Yup, that would do it.  That's much easier than trying to store state
> from the first one.  So, when can I see a patch?


Here it is Sam.

It guarantees that any conditional predicate is never re-evaluated and,
as an extra bonus, it also speeds up the output() execution in presence
of a TMPL_ELSE tag.

It passed all the tests under both Linux and Windows and I've also added
a new test for HTML::Template::Expr (05random.t) which reproduces the
case showed by Jochen Cichon.

The patch is against Template.pm ver. 2.7.
The patch is attached to this message (as well as the new test) and also
listed below.

Feel free to remove my name from the comments (left there merely to
easily find the relevant lines, just in case a correction is needed or a
further refinement comes to my mind).

Cheers,
Emanuele.


--- Template.pm.original	Sat Jun 26 08:57:09 2004
+++ Template.pm	Wed Jul 13 03:35:03 2005
@@ -897,7 +897,7 @@
 # accesses into "objects".  I used to use 'use constant' but that
 # seems to cause occasional irritating warnings in older Perls.
 package HTML::Template::LOOP;
-sub TEMPLATE_HASH () { 0; }
+sub TEMPLATE_HASH () { 0 };
 sub PARAM_SET     () { 1 };
=20
 package HTML::Template::COND;
@@ -908,6 +908,7 @@
 sub JUMP_IF_TRUE       () { 2 };
 sub JUMP_ADDRESS       () { 3 };
 sub WHICH              () { 4 };
+sub UNCONDITIONAL_JUMP () { 5 };
 sub WHICH_IF           () { 0 };
 sub WHICH_UNLESS       () { 1 };
=20
@@ -2183,7 +2184,15 @@
 =09
 	my $else =3D
HTML::Template::COND->new($cond->[HTML::Template::COND::VARIABLE]);
 	$else->[HTML::Template::COND::WHICH] =3D
$cond->[HTML::Template::COND::WHICH];
-	$else->[HTML::Template::COND::JUMP_IF_TRUE] =3D not
$cond->[HTML::Template::COND::JUMP_IF_TRUE];
+
+	# <Emanuele Zeppieri>
+	# Removed because now unnecessary, as we'll unconditionally jump
over
+	#$else->[HTML::Template::COND::JUMP_IF_TRUE] =3D not
$cond->[HTML::Template::COND::JUMP_IF_TRUE];
+
+	# This is to mark this COND opcode as generated by a TMPL_ELSE
tag,
+	# so that we can just jump over during the output() execution.
+	$else->[HTML::Template::COND::UNCONDITIONAL_JUMP] =3D 1;
+	# </Emanuele Zeppieri>
 =09
 	# need end-block resolution?
 	if (defined($cond->[HTML::Template::COND::VARIABLE_TYPE])) {
@@ -2201,7 +2210,7 @@
 	# the IF fails and falls though, output will reach the else
 	# and jump to the /if address.
 	$cond->[HTML::Template::COND::JUMP_ADDRESS] =3D $#pstack;
-=09
+	=09
       } elsif ($which eq 'TMPL_INCLUDE') {
 	# handle TMPL_INCLUDEs
 	$options->{debug} and print STDERR "### HTML::Template Debug ###
$fname : line $fcounter : INCLUDE $name \n";
@@ -2657,7 +2666,12 @@
         croak("HTML::Template->output() : fatal error in loop output :
$@")=20
           if $@;
       }
-    } elsif ($type eq 'HTML::Template::COND') {
+	} elsif ($type eq 'HTML::Template::COND') {
+    =09
+		if ($line->[HTML::Template::COND::UNCONDITIONAL_JUMP]) {
+			$x =3D $line->[HTML::Template::COND::JUMP_ADDRESS]
+		} else {
+    =09
       if ($line->[HTML::Template::COND::JUMP_IF_TRUE]) {
         if ($line->[HTML::Template::COND::VARIABLE_TYPE] =3D=3D
HTML::Template::COND::VARIABLE_TYPE_VAR) {
           if (defined ${$line->[HTML::Template::COND::VARIABLE]}) {
@@ -2689,6 +2703,9 @@
              not scalar
@{$line->[HTML::Template::COND::VARIABLE][HTML::Template::LOOP::PARAM_SE
T]});
         }
       }
+     =20
+		}
+      =09
     } elsif ($type eq 'HTML::Template::NOOP') {
       next;
     } elsif ($type eq 'HTML::Template::DEFAULT') {

Re: [htmltmpl] Nesting TMPL tags

[Mark F. <mar...@ea...>]

From: "Rajesh_K" <Raj...@Sa...>
>Is this part of the HTML::Template::expr package?  I don't see any %...%
construct in HTML::Template. Sorry I am asking you this... ppm is down
at activestate and I cant get at the expr module!

Rajesh,

Philip is suggesting that you markup your template so that you can perform
substitution upon a token inside the template using the "filter" parameter
to the "new" method.  You can mark it up any way you want. He's suggesting
you use % characters to make it unique.

Then you do something like this:

=========
my $filter = sub {
 my $text_ref = shift;

  $$text_ref =~
  s#MY_INCLUDE#$include_filename#g;

} # end filter

$template = $HTML::Template->new($page . '.html',
    filter => [
       { sub => $filter,
         format => 'scalar' },
       ]);
==========

Or, as I said, you can use the "path" parameter to the "new" method and pass
it multiple paths (some or all of which are defined at the time the "new"
method is called.). If you can organize your includes into directories
matching the criteria by which you'd like to load them with TMPL_VAR, you
could effectively accomplish the same thing by specifying variables on the
path parameter.

I had a *really* hard time with this concept because I believed H::T was
pulling in the includes at the time it is output. I too thought I should be
able to use TMPL_VAR to change include names. But, it's pulling them in at
the time you call "new." So, your choice is to organize them into
directories and use multiple paths for H::T to search. Or, use the filter to
change values to what you want them to be (before it evaluates the TMPL_
tags).

Mark

RE: [htmltmpl] Nesting TMPL tags

[Philip T. <phi...@gm...>]

Sometime Today, R cobbled together some glyphs to say:

> Is this part of the HTML::Template::expr package?  I don't see any
> %...% construct in HTML::Template. Sorry I am asking you this... ppm
> is down at activestate and I cant get at the expr module!

No, you have to write your own code to parse it.  You can use any
format you like.  I just picked %...% at random.  Look at the
documentation for HTML::Template, specifically the 'filter' parameter to
the constructor.

Philip

-- 
Would you *______really* want to get on a non-stop flight?
		-- George Carlin

RE: [htmltmpl] Nesting TMPL tags

[Rajesh_K <Raj...@Sa...>]

Hi Mark, Philip,

Is this part of the HTML::Template::expr package?  I don't see any %...%
construct in HTML::Template. Sorry I am asking you this... ppm is down
at activestate and I cant get at the expr module!

Rajesh

-----Original Message-----
From: htm...@li...
[mailto:htm...@li...] On Behalf Of
Mark A. Fuller
Sent: Tuesday, July 12, 2005 7:17 PM
To: Philip Tellis; HTML::Template List
Subject: Re: [htmltmpl] Nesting TMPL tags

From: Philip Tellis <phi...@gm...>
>> I want to TMPL_INCLUDE files, the problem is that the file I want to
>> include itself is variable. I want a construct of the sort
>>
>> <TMPL_INCLUDE NAME=3D"<TMPL_VAR NAME=3Dfile_name>">
>
> ...  What you want is to use a filter that
>preprocesses your template.  Change your template to something like
>this:
>
><TMPL_INCLUDE NAME=3D"%file_name%">

Or, organize your included templates into directories that can be
referenced with the "path =3D>" parameter to the "new" method. Something
like:

path =3D> [ '/path/to/templates',
               '/' . $include . '/path' ]

Mark


-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by
HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users



DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated.

Re: [htmltmpl] Nesting TMPL tags

[Mark A. F. <mar...@ea...>]

From: Philip Tellis <phi...@gm...>
>> I want to TMPL_INCLUDE files, the problem is that the file I want to
>> include itself is variable. I want a construct of the sort
>>
>> <TMPL_INCLUDE NAME="<TMPL_VAR NAME=file_name>">
>
> ...  What you want is to use a filter that
>preprocesses your template.  Change your template to something like
>this:
>
><TMPL_INCLUDE NAME="%file_name%">

Or, organize your included templates into directories that can be referenced with the "path =>" parameter to the "new" method. Something like:

path => [ '/path/to/templates',
               '/' . $include . '/path' ]

Mark

Re: [htmltmpl] Nesting TMPL tags

[Philip T. <phi...@gm...>]

Sometime Today, R cobbled together some glyphs to say:

> I want to TMPL_INCLUDE files, the problem is that the file I want to
> include itself is variable. I want a construct of the sort
>
> <TMPL_INCLUDE NAME="<TMPL_VAR NAME=file_name>">

You can't do this directly.  What you want is to use a filter that
preprocesses your template.  Change your template to something like
this:

<TMPL_INCLUDE NAME="%file_name%">

and then use a filter in your code that replaces %file_name% with the
actual file name.  Pass this to the HTML::Template constructor.

Oh yeah, I think we just violated Satyam's disclaimer at the bottom of
your email.

Philip

-- 
   From now on, I'll connect the dots my own way.
		  -- Calvin

[htmltmpl] Nesting TMPL tags

[Rajesh_K <Raj...@Sa...>]

Hi,

=20

I want to TMPL_INCLUDE files, the problem is that the file I want to
include itself is variable. I want a construct of the sort=20

<TMPL_INCLUDE NAME=3D"<TMPL_VAR NAME=3Dfile_name>">

=20

Obviously, in my PERL script, I have a=20

$template->param(file_name=3D>$filename);

=20

While the manual speaks of=20

<IMG SRC=3D"<TMPL_VAR NAME=3Dimage_name>">, there is no such feature
provided for what I have stated above. Further, this also throws up a
syntax error. Apache error log is given below.

=20

[Tue Jul 12 01:29:57 2005] [error] [client 127.0.0.1] Premature end of
script headers: yes.pl, referer:
http://localhost/cgi-bin/yes.pl?username=3Dbawa&password=3Dbawa&rm=3Dlogi=
n_val
idate

[Tue Jul 12 01:29:57 2005] [error] [client 127.0.0.1] Error executing
run mode 'admin_add_user': HTML::Template->new() : Syntax error in
<TMPL_*> tag at F:\Program Files\Apache
Group\Apache2\htdocs\yes\admin_tmpl.html : 10. at
C:/Perl/site/lib/HTML/Template.pm line 2288., referer:
http://localhost/cgi-bin/yes.pl?username=3Dbawa&password=3Dbawa&rm=3Dlogi=
n_val
idate

[Tue Jul 12 01:29:57 2005] [error] [client 127.0.0.1]  at F:/Program
Files/Apache Group/Apache2/cgi-bin/yes.pl line 4, referer:
http://localhost/cgi-bin/yes.pl?username=3Dbawa&password=3Dbawa&rm=3Dlogi=
n_val
idate

=20

Regards,

Rajesh



DISCLAIMER:
This email (including any attachments) is intended for the sole use of =
the intended recipient/s and may contain material that is CONFIDENTIAL =
AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or =
copying or distribution or forwarding of any or all of the contents in =
this message is STRICTLY PROHIBITED. If you are not the intended =
recipient, please contact the sender by email and delete all copies; =
your cooperation in this regard is appreciated.

RE: [htmltmpl] (no subject)

[Emanuele Z. <em...@li...>]

> -----Original Message-----
> From: htm...@li... 
> [mailto:htm...@li...] On 
> Behalf Of Sam Tregar
> Sent: Monday, July 11, 2005 8:00 PM
> To: Emanuele Zeppieri
> Cc: htm...@li...
> Subject: Re: [htmltmpl] (no subject)
> 
> 
> On Mon, 11 Jul 2005, Emanuele Zeppieri wrote:
> 
> > Well, I'm probably missing something (or everything), but 
> it seems to me
> > that the following compiled code layout could solve the problem:
> > 
> > 	JUMP to A IF false
> > 	... # first true instruction
> > 	...
> > 	... # last true instruction
> > 	JUMP TO B
> > A: 	... # first false instruction
> > 	...
> > 	... # last false instruction
> > B:	... # normal execution after the IF/ELSE, if any...
> 
> Yup, that would do it.  That's much easier than trying to store state
> from the first one.  So, when can I see a patch?

Well, I just didn't want to steal such a privilege to the person who
originally pointed out this issue ;-)

Joking apart, I'll be more than happy to work on a patch, as soon as my
clients give me a break and my newborn first son here will stop crying!

Any further hint about it?

--Emanuele.

Re: [htmltmpl] (no subject)

[Sam T. <sa...@tr...>]

On Mon, 11 Jul 2005, Emanuele Zeppieri wrote:

> Well, I'm probably missing something (or everything), but it seems to me
> that the following compiled code layout could solve the problem:
> 
> 	JUMP to A IF false
> 	... # first true instruction
> 	...
> 	... # last true instruction
> 	JUMP TO B
> A: 	... # first false instruction
> 	...
> 	... # last false instruction
> B:	... # normal execution after the IF/ELSE, if any...

Yup, that would do it.  That's much easier than trying to store state
from the first one.  So, when can I see a patch?

-sam

Re: [htmltmpl] (no subject)

[Emanuele Z. <em...@li...>]

> -----Original Message-----
> From: htm...@li...=20
> [mailto:htm...@li...] On=20
> Behalf Of Sam Tregar
> Sent: Monday, July 11, 2005 4:50 PM
> To: Jochen Cichon
> Cc: htm...@li...
> Subject: Re: [htmltmpl] (no subject)
>=20
>=20
> On Mon, 11 Jul 2005, Jochen Cichon wrote:
>=20
> > Hm, was my first Idea also,
> >=20
> > but why is condition evaluated a second time ONLY if it is=20
> TRUE on the first
> > run?
>=20
> HTML::Template compiles an IF/ELSE into two JUMP IF ops:
>=20
>      JUMP to A IF false
>      ...
>      ...
>      JUMP TO B IF true
>   A: ...
>      ...
>      ...
>   B: ...

Well, I'm probably missing something (or everything), but it seems to me
that the following compiled code layout could solve the problem:

	JUMP to A IF false
	... # first true instruction
	...
	... # last true instruction
	JUMP TO B
A: 	... # first false instruction
	...
	... # last false instruction
B:	... # normal execution after the IF/ELSE, if any...


Anyway I would say that, in general, re-evaluating twice the predicate
for a single IF/ELSE clause execution should be avoided at all costs.

Ciao,
Emanuele.

Re: [htmltmpl] (no subject)

[Sam T. <sa...@tr...>]

On Mon, 11 Jul 2005, Jochen Cichon wrote:

> Hm, was my first Idea also,
> 
> but why is condition evaluated a second time ONLY if it is TRUE on the first
> run?

HTML::Template compiles an IF/ELSE into two JUMP IF ops:

     JUMP to A IF false
     ...
     ...
     JUMP TO B IF true
  A: ...
     ...
     ...
  B: ...

Thus a false condition is only tested once, but a true condition gets
tested twice.  The trick will be to link the two jumps so that the
second one re-examines the result of the first rather than running the
code again.

-sam

Re: [htmltmpl] (no subject)

[Jochen C. <htm...@dh...>]

Hm, was my first Idea also,

but why is condition evaluated a second time ONLY if it is TRUE on the 
first run?

I have looked into the source, but was not sure of it's a problem of the 
resolving ... or maybe of the parser?

-- 
Jochen

Sam Tregar schrieb:
> On Fri, 8 Jul 2005, Jochen Cichon wrote:
> 
> 
>>Any Ideas?
>>
>>
>>It seems not to be a problem with the rand, it seems more to be a
>>problem when the expr is somehow different in the two runs.  So why
>>is ist pared twice? (sometimes!)
> 
> 
> I think it's because HTML::Template is evaluating the condition twice
> - once in the "TMPL_IF" and once in the "TMPL_ELSE".  This usually
> works fine since most boolean conditions are stable but not for
> rand()!  If you're interested in fixing this the relevent code is in
> HTML::Template::output().  I think this could be quite challenging to
> fix!
> 
> -sam
> 
> 

Re: [htmltmpl] (no subject)

[Sam T. <sa...@tr...>]

On Fri, 8 Jul 2005, Jochen Cichon wrote:

> Any Ideas?
> 
> 
> It seems not to be a problem with the rand, it seems more to be a
> problem when the expr is somehow different in the two runs.  So why
> is ist pared twice? (sometimes!)

I think it's because HTML::Template is evaluating the condition twice
- once in the "TMPL_IF" and once in the "TMPL_ELSE".  This usually
works fine since most boolean conditions are stable but not for
rand()!  If you're interested in fixing this the relevent code is in
HTML::Template::output().  I think this could be quite challenging to
fix!

-sam

[htmltmpl] (no subject)

[Jochen C. <htm...@dh...>]

Hi,

i found a nice bug (that keeps me awake for about 3 hours...)


I have the following template:

<tmpl_if expr="(int(rand(2))==0">
   YES
<tmpl_else>
   NO
</tmpl_if>

which is not that complicated.


When you run the program, and the expr is evaluated to FASLSE then there 
is no problem and you get
     NO
in the outut.

BUT (!) if the expr is TRUE then the document is parsed again (don't ask 
why) and now comes the clue.
IF the expr on the second run returns the same result as on the first 
run, you will get
     YES
but if the results are different on the two runs you will get
     YES
     NO

... Whoops.


Any Ideas?


It seems not to be a problem with the rand, it seems more to be a 
problem when the expr is somehow different in the two runs.

So why is ist pared twice? (sometimes!)

Re: [htmltmpl] Bug in die_on_bad_params handling

[Mark F. <mar...@ea...>]

From: "Sam Tregar" <sa...@tr...>
> The loop output code calls param() to setup each row.

I see it now. The output method calls the package HTML::Template::LOOP which
calls param(). It would take some work to 1) collect (in a hash)
die_on_bad_param flags when the user calls param() with an array (or
arrays). And then 2) use that hash to set the global value from inside
HTML::Template::LOOP prior to calling param().

The overhead involved in doing that starts to diminish the cost of using the
same table structure and pass empty strings when not needed. Or, using a
TMPL_IF (as Roger suggested).

Also, if the data associated with two loops is so large that it's costly to
create a data structure for each one, that seems to indicate it should be
displayed in two pages. To the extent it's difficult for the computer, I'd
think it's at least that difficult for whoever's on the receiving end. :)

Thanks,
Mark

Re: [htmltmpl] Bug in die_on_bad_params handling

[Roger B. W. <ro...@fi...>]

(A work-around, expanding on Mark Fuller's suggestion:)

On Thu, Jul 07, 2005 at 02:27:08PM +0200, Matija Grabnar wrote:

><tmpl_loop name="foo">
> <tmpl_var name="bar">
> <tmpl_var name="baz">
></tmpl_loop>
><tmpl_loop name="foo">
> <tmpl_var name="baz">

<tmpl_if name="bar"></tmpl_if>

></tmpl_loop>

R

Re: [htmltmpl] Bug in die_on_bad_params handling

[Sam T. <sa...@tr...>]

On Thu, 7 Jul 2005, Mark Fuller wrote:

> From: "Sam Tregar" <sa...@tr...>
> > That's a run-time error that happens during output() and the relevent file
> and
> > line numbers are currently only available during parse().
> 
> Sam, I'm curious: Why wouldn't my suggestion work?

I didn't mean to imply that it wouldn't.  I only meant to express my
delight that someone might do the work to add filenames and
line-numbers to die_on_bad_params errors.

> The croaked message Matija referred to is in the param method. I
> can't find it anywhere else.  How does it reach the output method if
> it is croaking on this line as the param is set?

The loop output code calls param() to setup each row.

-sam

Re: [htmltmpl] Bug in die_on_bad_params handling

[Mark F. <mar...@ea...>]

From: "Sam Tregar" <sa...@tr...>
> That's a run-time error that happens during output() and the relevent file
and
> line numbers are currently only available during parse().

Sam, I'm curious: Why wouldn't my suggestion work? The croaked message
Matija referred to is in the param method. I can't find it anywhere else.
How does it reach the output method if it is croaking on this line as the
param is set?

After thinking about it: it seems like it would be easier for Matija to
provide all the vars in a tmpl_loop, passing empty strings (instead of
turning off "die_on_bad_params" and so H::T will fill ignore extra columns).
Or, maintain seperate loop names.

Mark

Re: [htmltmpl] Bug in die_on_bad_params handling

[Mark F. <mar...@ea...>]

From: "Matija Grabnar" <mat...@ar...>
> Setting up the loops would be expensive, since it involves a LOT of data

You may already know this. It would be fairly easy for you to subclass H::T
to use your own modified param method. Modify it to accept a second
parameter:

========
@foo=({bar=>1,baz=>2},{bar=>3,baz=>4});
@die=(1,0);
$t->param(foo=>\@foo, \@die);
========

Then, in the param method's loop have it test the corresponding die
parameter instead of the global setting.

BTW: I think your request makes *a lot* of sense. I'd call it an enhancement
instead of a bug.

Mark

Re: [htmltmpl] Bug in die_on_bad_params handling

[Sam T. <sa...@tr...>]

On Thu, 7 Jul 2005, Matija Grabnar wrote:

> And die_on_bad_params is usualy a very usefull debugging tool, which
> is why I need it.  At least, if it dies in the loop, HTML::Template
> should tell you WHICH loop it died in (in which line the loop
> began).

Now that's a patch I'd take!  Warning - it won't be easy.  That's a
run-time error that happens during output() and the relevent file and
line numbers are currently only available during parse().

-sam

Re: [htmltmpl] Bug in die_on_bad_params handling

[Matija G. <mat...@ar...>]

Jason Purdy wrote:

> IMVHO, this isn't a bug, but rather the intended behavior.  If you 
> really want to be strict about it, set up two different loops. 
> Otherwise, don't worry about die_on_bad_params.
>
> - Jason

Setting up the loops would be expensive, since it involves a LOT of data 
- it would
be stupid to waste all that memory just because one of the loops uses 
one less variable
then the other.

And die_on_bad_params is usualy a very usefull debugging tool, which is 
why I need it.
At least, if it dies in the loop, HTML::Template should tell you WHICH 
loop it died in
(in which line the loop began).

Matija

Re: [htmltmpl] Bug in die_on_bad_params handling

[Jason P. <ja...@jo...>]

IMVHO, this isn't a bug, but rather the intended behavior.  If you 
really want to be strict about it, set up two different loops. 
Otherwise, don't worry about die_on_bad_params.

- Jason

Matija Grabnar wrote:
> For example
> Template:
> 
> <tmpl_loop name="foo">
>  <tmpl_var name="bar">
>  <tmpl_var name="baz">
> </tmpl_loop>
> <tmpl_loop name="foo">
>  <tmpl_var name="baz">
> </tmpl_loop>
> 
> Script:
> #!/usr/bin/perl
> use HTML::Template;
> $t=HTML::Template->new(filename=>'0.tmpl');
> @foo=({bar=>1,baz=>2},{bar=>3,baz=>4});
> $t->param(foo=>\@foo);
> print $t->output;
> 
> Result:
> HTML::Template->output() : fatal error in loop output : HTML::Template : 
> Attempt to set nonexistent parameter 'bar' - this parameter name doesn't 
> match any declarations in the template file : (die_on_bad_params => 1) 
> at /usr/share/perl5/HTML/Template.pm line 2905
> at 0.pl line 6
> at /usr/share/perl5/HTML/Template.pm line 2613
>        HTML::Template::output('HTML::Template=HASH(0x81f283c)') called 
> at 0.pl line 6
> 
> Obviously, this error is wrong: bar does appear, just not in EVERY 
> instance of the loop. I could
> turn die_on_bad_params off, but then I don't get help in finding REAL 
> errors, and I need it
> (because the actual template where I need this is much, much more 
> complex than this
> example).
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] Bug in die_on_bad_params handling

[Matija G. <mat...@ar...>]

For example
Template:

<tmpl_loop name="foo">
  <tmpl_var name="bar">
  <tmpl_var name="baz">
</tmpl_loop>
<tmpl_loop name="foo">
  <tmpl_var name="baz">
</tmpl_loop>

Script:
#!/usr/bin/perl
use HTML::Template;
$t=HTML::Template->new(filename=>'0.tmpl');
@foo=({bar=>1,baz=>2},{bar=>3,baz=>4});
$t->param(foo=>\@foo);
print $t->output;

Result:
HTML::Template->output() : fatal error in loop output : HTML::Template : 
Attempt to set nonexistent parameter 'bar' - this parameter name doesn't 
match any declarations in the template file : (die_on_bad_params => 1) 
at /usr/share/perl5/HTML/Template.pm line 2905
 at 0.pl line 6
 at /usr/share/perl5/HTML/Template.pm line 2613
        HTML::Template::output('HTML::Template=HASH(0x81f283c)') called 
at 0.pl line 6

Obviously, this error is wrong: bar does appear, just not in EVERY 
instance of the loop. I could
turn die_on_bad_params off, but then I don't get help in finding REAL 
errors, and I need it
(because the actual template where I need this is much, much more 
complex than this
example).

Re: [htmltmpl] HTML::Template for WML

[Alex K. <ka...@ra...>]

* Mathew Robertson <mat...@re...> [June 29 2005, 02:37]:
> > As far as I understand the only way to add an ESCAPE filter is to
> > hack _parse method (subclassing or just patching). Looks like
> > ESCAPE filters are all hardwired and spread over the code of the method.
> > 
> > Did anyone face these problems? Or is WML that dead and no one cares
> > about it anymore? :)
> 
> I also found that it was quite hard to plugin custom ESCAPE types -
> so I modified my copy of H::T so that the escaping code is handled
> by subclasses of a new H::T::ESCAPE module.
> 
> The idea is that you subclasss H::T::ESCAPE, then submit the new
> escape-type back for everyone else to use.  You can download my
> version of H::T here:  http://members.optusnet.com.au/mathew

This is great! I see there more features I'd like to use, not only
custom ESCAPErs! I strongly advise you to upload your work to CPAN
as a HTML::Template fork. Those features will certainly benefit a 
wider audience.

I'm going to try to port your ESCAPE abstraction to HT::JIT as that's
really what we use in production.

-- 
Alex Kapranoff,
$n=["1another7Perl213Just3hacker49"=~/\d|\D*/g];
$$n[0]={grep/\d/,@$n};print"@$n{1..4}\n"