HTML::Template

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
> Html-template-users@...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

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

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

From: "Matija Grabnar" <matija.grabnar@...>
> 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

From: "Sam Tregar" <sam@...>
> 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

On Thu, 7 Jul 2005, Mark Fuller wrote:

> From: "Sam Tregar" <sam@...>
> > 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

(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

From: "Sam Tregar" <sam@...>
> 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