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

[htmltmpl] [Question] Clearing <TMPL_LOOP> content after first pass

[C H. <hag...@ep...>]

I'm struggling with a <TMP_LOOP> problem ...

Using a subroutine call:

if ( $q->param('action') eq 'one') {
         CallSubroutine('Red');
}

I send a "select" call to a MySql table.
The subroutine call includes a value that
determines what records are returned. I
"grab" what the select call returns using:

my $res = $sth->fetchall_arrayref({});

...................

assign it to a parameter:

$q->param(res => $res);

...................

call the template using "associate"

my $template = HTML::Template->new(
         filename => 'template_filename.tmpl',
         associate => $q,
);

..................

write the template content to a file

open (FILE,">$filename") or die "no $filname!\n";
$template->output(print_to => *FILE);
close(FILE);

..................

the template looks like:

<TMPL_LOOP res>
All kinds of HTML stuff here, including
<TMPL_VAR NAME=whatever> values
</TMPL_LOOP>

........................

The above works fine. The problem I'm having is when
I call the subroutine twice - each time sending a
different value:

if ( $q->param('action') eq 'two') {
         CallSubroutine('Red');
         CallSubroutine('Blue');
}

The output is written to the correct two
files, *but* the content of the files is identical,
and always matches the content of the first
iteration of the subroutine:

if ( $q->param('action') eq 'two') {
         CallSubroutine('Red');
         CallSubroutine('Blue');
}

produces two identical files with the "Red" content

if ( $q->param('action') eq 'two') {
         CallSubroutine('Blue');
         CallSubroutine('Red');
}

produces two identical files with the "Blue" content.
It appears that the template "storing" the first
loop content, and not letting it go when the
subroutine is called the second time.

I'm an H::T newbie ... maybe there's something
obvious I'm missing?

Carl Hagstrom

Re: [htmltmpl] [patch] HT::JIT .so-s die while urlescaping 8bit chars

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

* Sam Tregar <sa...@tr...> [May 19 2004, 20:55]:
> On Wed, 19 May 2004, Alex Kapranoff wrote:
> 
> > The patch is obvious. There's a test for the case, too.
> 
> Hey, thanks!  Does it work with UTF-8 in the template text too?  I had
> a theory that that wouldn't work either...

  Works For Me (TM) At least with GCC.
  By the way, why shouldn't it? GCC doesn't mind 8bit octets(bytes) in
source code and you don't bother with (wide)?character vs. byte
issues either :)

  UTF-8 string is just an array of bytes and there won't be problems
if you treat it as opaque string. At least I suppose so.

  However, there SHOULD be problems when escaping UTF-8 params data as
your code iterates over it using C chars which are bytes really.  But I
don't face them right now. That's weird as almost all my params come
in UTF-8 :)

-- 
Alex Kapranoff.

Re: [htmltmpl] [patch] HT::JIT .so-s die while urlescaping 8bit chars

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

On Wed, 19 May 2004, Sam Tregar wrote:

> On Wed, 19 May 2004, Alex Kapranoff wrote:
>
> > The patch is obvious. There's a test for the case, too.
>
> Hey, thanks!  Does it work with UTF-8 in the template text too?  I had
> a theory that that wouldn't work either...

Ignore me.  My coffee-less brain read "8bit" as "UTF-8".

-sam

Re: [htmltmpl] [patch] HT::JIT .so-s die while urlescaping 8bit chars

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

On Wed, 19 May 2004, Alex Kapranoff wrote:

> The patch is obvious. There's a test for the case, too.

Hey, thanks!  Does it work with UTF-8 in the template text too?  I had
a theory that that wouldn't work either...

-sam

[htmltmpl] [patch] HT::JIT .so-s die while urlescaping 8bit chars

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

The patch is obvious. There's a test for the case, too.

--- Compiler.pm.orig	Tue May 18 18:32:59 2004
+++ JIT/Compiler.pm	Tue May 18 18:33:52 2004
@@ -131,7 +131,7 @@
   SV * temp_sv;
   int i;
   STRLEN len;
-  char c;
+  unsigned char c;
   char buf[4];
 
   SvPOK_on(result);


--- 10escape.t.orig	Tue May 18 18:39:12 2004
+++ 10escape.t	Tue May 18 18:42:03 2004
@@ -1,4 +1,4 @@
-use Test::More tests => 3;
+use Test::More tests => 4;
 use HTML::Template::JIT;
 my $debug = 0;
 
@@ -35,3 +35,13 @@
 $output = $template->output;
 like($output, qr/Some URL escaped stuff:/); 
 
+# test 8bit char in urlescaped var
+$template = HTML::Template::JIT->new(
+                                     filename => 'urlescape.tmpl',
+                                     path => ['t/templates'],
+                                     jit_path => 't/jit_path',
+                                     jit_debug => $debug,
+                                    );
+$template->param(STUFF => "\xf4"); #"
+$output = $template->output;
+like($output, qr/%F4/); #"


-- 
Alex Kapranoff.

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

Hi Sam, 

Did you decide on what to do with the submitted patch? 

simran.


On Wed, 2004-05-12 at 16:51, simran wrote:
> very good points :-) 
> 
> How is the attached as a patch... 
> 
> simran.
> 
> 
> 
> 
> On Wed, 2004-05-12 at 14:09, Sam Tregar wrote:
> > On Wed, 12 May 2004, simran wrote:
> > 
> > > +        foreach my $row (@$value) {
> > > +          foreach my $key (keys %$row) {
> > > +            $row->{$key} ||= "";
> > > +          }
> > > +        }
> > 
> > Hmmmm.  What happens when $row->{$key} is "0"?  What happens when
> > undef is set in a loop within a loop?
> > 
> > I think the real fix is to find a way to use exists() rather than
> > defined() when looking for the variable setting.  That way it doesn't
> > matter what the value of the var is, just whether it's set or not.
> > Maybe you could give that a try?
> > 
> > Thanks,
> > -sam
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> > deliver higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Html-template-users mailing list
> > Htm...@li...
> > https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] inconsistent file_cache behavior

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

try 'perldoc HTML::Template' then search for filter... the first thing =
it says is:

filter - this option allows you to specify a filter for your
               template files.  A filter is a subroutine that will be =
called
               after HTML::Template reads your template file but before =
it
               starts parsing template tags.


thus, filtering is only applied on file load (ie when the tamplate is =
parsed for tags).  Since caching wont allow the file to reload unless it =
changes, the filer is not re-applied.

To solve this, you can either:
a) disable caching if you want to keep the filter
b) re-implement the template so that you dont need to use a filter, by =
using TMPL_IF and TMPL_INCLUDE

Hope this helps,
Mathew


----- Original Message -----=20
From: "Nishikant Kapoor" <nk...@we...>
To: "T Mailing List" <htm...@li...>
Sent: Monday, May 17, 2004 3:56 PM
Subject: Re: [htmltmpl] inconsistent file_cache behavior


> Sam Tregar wrote:
> > On Sun, 16 May 2004, Nishikant Kapoor wrote:
> >=20
> >>I do edit the template by hand but in this case, the mtime on the
> >>template is not changing. However, the content for the template =
needs to
> >>change based on whether the user is logged-in or logged-out.
> >=20
> >=20
> > Well that has nothing to do with the file cache.  To convince
> > yourself, turn it off and observe that nothing changes!  The file
> > cache is just saving HTML::Template the trouble of loading the
> > template from disk every time it needs it.  It has nothing to do =
with
> > the output - that's driven by your calls to param(), which are reset
> > after every new().
>=20
> Okay, here is what I think is happening.
>=20
> index.shtml:
> ...
>    <!--#exec cgi=3D"/cgi-bin/featuredLinks.cgi"-->
> ...
>=20
> When you login or logout, sub showHome() is called.
>=20
> sub showHome {
> ...
>    my $filter =3D sub {
>      my $textRef =3D shift;
>=20
>      my $strToReplace =3D 'featuredLinks.cgi';
>      if ($$textRef =3D~ /(.*cgi=3D\")(.*$strToReplace)(\".*)/) {
>        my $strToReplaceWith =3D &getFeaturedLinks;
>        $$textRef =3D~ =
s/(.*cgi=3D\")(.*$strToReplace)(\".*)/$strToReplaceWith/g;
>      }
>    };
>=20
>    my $template =3D HTML::Template->new(filename =3D> 'index.shtml',
>                                       file_cache =3D> 1,
>                                       file_cache_dir =3D> 'tmplCache',
>                                       file_cache_dir_mode =3D> 0777,
>                                       filter =3D> $filter);
> ...
> } #end of showHome()
>=20
> When file_cache is ON, template is being returned from the cache,=20
> thereby bypassing the $filter which is actually responsible for =
getting=20
> the appropriate data based on user's login status and hence, the=20
> inconsistency. Does this look like what is going on here? If so, what=20
> would you suggest be the workaround?
>=20
> Thanks,
> Nishi
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

Re: [htmltmpl] inconsistent file_cache behavior

[Nishikant K. <nk...@we...>]

Sam Tregar wrote:
> On Sun, 16 May 2004, Nishikant Kapoor wrote:
> 
>>I do edit the template by hand but in this case, the mtime on the
>>template is not changing. However, the content for the template needs to
>>change based on whether the user is logged-in or logged-out.
> 
> 
> Well that has nothing to do with the file cache.  To convince
> yourself, turn it off and observe that nothing changes!  The file
> cache is just saving HTML::Template the trouble of loading the
> template from disk every time it needs it.  It has nothing to do with
> the output - that's driven by your calls to param(), which are reset
> after every new().

Okay, here is what I think is happening.

index.shtml:
...
   <!--#exec cgi="/cgi-bin/featuredLinks.cgi"-->
...

When you login or logout, sub showHome() is called.

sub showHome {
...
   my $filter = sub {
     my $textRef = shift;

     my $strToReplace = 'featuredLinks.cgi';
     if ($$textRef =~ /(.*cgi=\")(.*$strToReplace)(\".*)/) {
       my $strToReplaceWith = &getFeaturedLinks;
       $$textRef =~ s/(.*cgi=\")(.*$strToReplace)(\".*)/$strToReplaceWith/g;
     }
   };

   my $template = HTML::Template->new(filename => 'index.shtml',
                                      file_cache => 1,
                                      file_cache_dir => 'tmplCache',
                                      file_cache_dir_mode => 0777,
                                      filter => $filter);
...
} #end of showHome()

When file_cache is ON, template is being returned from the cache, 
thereby bypassing the $filter which is actually responsible for getting 
the appropriate data based on user's login status and hence, the 
inconsistency. Does this look like what is going on here? If so, what 
would you suggest be the workaround?

Thanks,
Nishi

Re: [htmltmpl] inconsistent file_cache behavior

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

> Sam Tregar wrote:
> > On Sun, 16 May 2004, Nishikant Kapoor wrote:
> >=20
> >>Apparently, 'featuredLinks.cgi' is returning the template from the =
cache
> >>when I expect it to generate a new one. This is how I am calling the
> >>template:
> >>
> >>   my $tmpl =3D HTML::Template->new(filename =3D> $linksTmpl,
> >>                                  file_cache =3D> 1,
> >>                                  file_cache_dir =3D> 'tmplCache',
> >> file_cache_dir_mode =3D> 0777);
> >=20
> >=20
> > What do you mean by 'generate a new one'?  Are you auto-generating
> > your templates in some way?  Usually templates are edited by hand =
and
> > the file_cache only refreshes when the mtime on the file changes due
> > to an edit.
>=20
> I meant that the template should get re-filled with default links when =
I=20
> log out rather than returning customized links (which were displayed=20
> when I was logged in).
>=20
> I do edit the template by hand but in this case, the mtime on the=20
> template is not changing. However, the content for the template needs =
to=20
> change based on whether the user is logged-in or logged-out.

This sounds like you are using H::T incorrectly... somewhere in you =
template you should probably doing somthing like:

<TMPL_IF logged_in>
  <TMPL_INCLUDE logged_in.tmpl>
<TMPL_ELSE>
  <TMPL_INCLUDE default.tmpl>
</TMPL_IF>

You may need to put  more information in the email, as it appears that =
what you are trying to do, is reasonably simple thus you shouldn't =
really be getting stuck.

>=20
> >>Another issue, though not a big one. Even though I specify '0777' =
for
> >>creating file_cache_dir, I still get 'tmplCache' created with '0755'
> >>permissions.
> >=20
> >=20
> > Huh, that's odd.  I'm passing that mode as the second arg to =
mkdir().
> > That should work.  Are you sure you didn't create the directory
> > yourself?
>=20
> Yep, I made sure of that by removing 'tmplCache' and letting H::T =
create it.

This could be related to your 'uname' mask - if it is set to '022' then =
you have found your answer.

Mathew

Re: [htmltmpl] inconsistent file_cache behavior

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

On Sun, 16 May 2004, Nishikant Kapoor wrote:

> I do edit the template by hand but in this case, the mtime on the
> template is not changing. However, the content for the template needs to
> change based on whether the user is logged-in or logged-out.

Well that has nothing to do with the file cache.  To convince
yourself, turn it off and observe that nothing changes!  The file
cache is just saving HTML::Template the trouble of loading the
template from disk every time it needs it.  It has nothing to do with
the output - that's driven by your calls to param(), which are reset
after every new().

> > Huh, that's odd.  I'm passing that mode as the second arg to mkdir().
> > That should work.  Are you sure you didn't create the directory
> > yourself?
>
> Yep, I made sure of that by removing 'tmplCache' and letting H::T create it.

Interesting.  Maybe mkdir() is broken on your system.  I don't know
why that would be...

-sam

Re: [htmltmpl] inconsistent file_cache behavior

[Nishikant K. <nk...@we...>]

Sam Tregar wrote:
> On Sun, 16 May 2004, Nishikant Kapoor wrote:
> 
>>Apparently, 'featuredLinks.cgi' is returning the template from the cache
>>when I expect it to generate a new one. This is how I am calling the
>>template:
>>
>>   my $tmpl = HTML::Template->new(filename => $linksTmpl,
>>                                  file_cache => 1,
>>                                  file_cache_dir => 'tmplCache',
>>				 file_cache_dir_mode => 0777);
> 
> 
> What do you mean by 'generate a new one'?  Are you auto-generating
> your templates in some way?  Usually templates are edited by hand and
> the file_cache only refreshes when the mtime on the file changes due
> to an edit.

I meant that the template should get re-filled with default links when I 
log out rather than returning customized links (which were displayed 
when I was logged in).

I do edit the template by hand but in this case, the mtime on the 
template is not changing. However, the content for the template needs to 
change based on whether the user is logged-in or logged-out.

>>Another issue, though not a big one. Even though I specify '0777' for
>>creating file_cache_dir, I still get 'tmplCache' created with '0755'
>>permissions.
> 
> 
> Huh, that's odd.  I'm passing that mode as the second arg to mkdir().
> That should work.  Are you sure you didn't create the directory
> yourself?

Yep, I made sure of that by removing 'tmplCache' and letting H::T create it.

Thanks
Nishi

Re: [htmltmpl] inconsistent file_cache behavior

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

On Sun, 16 May 2004, Nishikant Kapoor wrote:

> Apparently, 'featuredLinks.cgi' is returning the template from the cache
> when I expect it to generate a new one. This is how I am calling the
> template:
>
>    my $tmpl = HTML::Template->new(filename => $linksTmpl,
>                                   file_cache => 1,
>                                   file_cache_dir => 'tmplCache',
> 				 file_cache_dir_mode => 0777);

What do you mean by 'generate a new one'?  Are you auto-generating
your templates in some way?  Usually templates are edited by hand and
the file_cache only refreshes when the mtime on the file changes due
to an edit.

> Another issue, though not a big one. Even though I specify '0777' for
> creating file_cache_dir, I still get 'tmplCache' created with '0755'
> permissions.

Huh, that's odd.  I'm passing that mode as the second arg to mkdir().
That should work.  Are you sure you didn't create the directory
yourself?

-sam

[htmltmpl] inconsistent file_cache behavior

[Nishikant K. <nk...@we...>]

I just started using file_cache and am seeing some unexpected behavior. 
Here is how I am using it.

The home page has a block 'Featured Links' which displays a set of 
default links.
If the user is logged in, he gets an additional link 'Customize' that 
enables him to customize these links and if he chooses do so, the 
customized links show up in the block instead of default ones.

Looks like, the 'Featured Links' block is behaving inconsistently i.e. 
sometimes after I log out, I continue to see the customized links. At 
other times, even after I log in, I still see the default links.

Apparently, 'featuredLinks.cgi' is returning the template from the cache 
when I expect it to generate a new one. This is how I am calling the 
template:

   my $tmpl = HTML::Template->new(filename => $linksTmpl,
                                  file_cache => 1,
                                  file_cache_dir => 'tmplCache',
				 file_cache_dir_mode => 0777);

Another issue, though not a big one. Even though I specify '0777' for 
creating file_cache_dir, I still get 'tmplCache' created with '0755' 
permissions.

Thanks
Nishi

Re: [htmltmpl] Coding up a three column table...

[Dave H. <da...@ho...>]

> (warning, totally untested, but it probably works)

Thanks Roger, that's an HTML idiom I'll use again :-)

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

good example -> given this , I would agreee that it is a bug.

... and yes you are correct, the stderr message is generated by 'use =
warnings' not 'use strict'.

Mathew

> > Relating this to TMPL_LOOP's... the question becomes, "Is a variable =
inside=20
> > a loop considered to be equivalent to a hash key, or equivalent to a =

> > variable?", alternatively it could be asked "What is the =
'strict'ness of=20
> > TMPL_LOOP variables (as compared to Perl's use of 'strict'ness)?".
> > =20
>=20
> According to the H::T docs ...
> "For the computer-science geeks among you, a <TMPL_LOOP> introduces a =
new
> scope much like a perl subroutine call."
> So the scope (when global vars is turned on) is that it should behave =
like a
> variable, not a hash (since it is a TMPL_VAR not a TMPL_KEY right :). =
For
> instance, the following simple script..
>=20
> #!/usr/bin/perl
> use strict;
>                                                                        =
     =20
>                                                                        =
       =20
> our $var =3D 'a test';
> &test();
>                                                                        =
     =20
>                                                                        =
       =20
> sub test
> {
>   my $var =3D 'another test';
>   $var =3D undef;
>   print "This is $var\n";
> }
>=20
> produces this output
> 'This is'
>=20
> Even with 'use strict' (and even with 'use warnings' STDOUT still gets =
this
> output even if STDERR get's the warning).
>=20
> So, in my opinion he is right. This is a bug. And I even think sam =
admitted it
> was and that somehow what was needed was to check 'exists' and not =
truthfulness.
>=20
>=20
> > Since we are talking about TMPL_LOOP variables, not Perl hash keys, =
it gets
> back to the question(s) posed above.
> >=20
> > > Another example:
> > >=20
> > > -- test.pl --
> > > #!/usr/bin/perl
> > > my $tvar =3D "this is a test";
> > > $tvar =3D undef;
> > > print "Tvar=3D$tvar\n";
> > > -----------------------------------------
> > > The above prints: Tvar=3D
> >=20
> > true - but only if you dont do:
> >=20
> > use strict;
> > use warnings;
>=20
> Even if you 'use strict' and 'use warnings' you get the right output =
(like I
> said before, on STDOUT even if you do get a 'warning' on STDERR)
>=20
>=20
> Michael Peters
> Venzia
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=3D2562&alloc_id=3D6184&op=3Dclick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

Re: [htmltmpl] Patch to fix global_vars and loop problem...

[petersm <pe...@ve...>]

Mathew Robertson wrote:


> Relating this to TMPL_LOOP's... the question becomes, "Is a variable inside 
> a loop considered to be equivalent to a hash key, or equivalent to a 
> variable?", alternatively it could be asked "What is the 'strict'ness of 
> TMPL_LOOP variables (as compared to Perl's use of 'strict'ness)?".
>  

According to the H::T docs ...
"For the computer-science geeks among you, a <TMPL_LOOP> introduces a new
scope much like a perl subroutine call."
So the scope (when global vars is turned on) is that it should behave like a
variable, not a hash (since it is a TMPL_VAR not a TMPL_KEY right :). For
instance, the following simple script..

#!/usr/bin/perl
use strict;
                                                                             
                                                                               
our $var = 'a test';
&test();
                                                                             
                                                                               
sub test
{
  my $var = 'another test';
  $var = undef;
  print "This is $var\n";
}

produces this output
'This is'

Even with 'use strict' (and even with 'use warnings' STDOUT still gets this
output even if STDERR get's the warning).

So, in my opinion he is right. This is a bug. And I even think sam admitted it
was and that somehow what was needed was to check 'exists' and not truthfulness.


> Since we are talking about TMPL_LOOP variables, not Perl hash keys, it gets
back to the question(s) posed above.
> 
> > Another example:
> > 
> > -- test.pl --
> > #!/usr/bin/perl
> > my $tvar = "this is a test";
> > $tvar = undef;
> > print "Tvar=$tvar\n";
> > -----------------------------------------
> > The above prints: Tvar=
> 
> true - but only if you dont do:
> 
> use strict;
> use warnings;

Even if you 'use strict' and 'use warnings' you get the right output (like I
said before, on STDOUT even if you do get a 'warning' on STDERR)


Michael Peters
Venzia

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

[...snip...]
> > Another example:
> > 
> > -- test.pl --
> > #!/usr/bin/perl
> > my $tvar = "this is a test";
> > $tvar = undef;
> > print "Tvar=$tvar\n";
> > -----------------------------------------
> > The above prints: Tvar=
> 
> true - but only if you dont do:
> 
> use strict;
> use warnings;

i do normally always use strict :-)... and putting them (use warnings,
strict) into the test.pl file above produces the same result... 

i do take your other points though... and i do believe that inside a
loop a "row" or data should be treated as a hash... as that's what is
actually is as well... but that is my opinion... would be interesting to
see what Sam things... as i guess it will be his decision in the end :-)
Personally though.. i have found that they way i use HTML::Template, i
found found the current behaviour to be contrary to my expectations... 
(and hence a bug in my eyes)
 
> 
> ... and I cant find a single reference suggesting to not use the 'use's.
> 
> 
> > Now, so in the same context if "undef" should mean... take the outer
> > scope, then perl should have ignored my "$tvar = undef" line... 
> 
> No - setting a value to 'undef' means - "remove me from the symbol table" - it doesnt mean, "make my value to be 'undef'" (although you get this behaviour if 'use strict' is not in effect).
> 
> 
> > I think its definitely a bug :-) 
> > It has infact been flagged before as well... its partially on a thread
> > at:
> > http://www.mail-archive.com/htm...@li.../msg00728.html
> > although that thread digressed a bit... but this topic has been bought
> > up a few times... so maybe we can find more threads about it in the
> > history of the list... 
> 
> fair enough - although, that doesn't constitute a reason to modify the behaviour.  A change to the code, should require us to agree on the answer to the question(s) posed above.
> 
> Mathew
> 
> 
> > 
> > 
> > 
> > 
> > 
> > > 
> > > thus requesting the outer global gvar to come into scope.
> > > 
> > > Consider:
> > > 
> > > t->param(gvar => "Global gvar");
> > > my $gvar_val;
> > > my @loop;
> > > for.... {
> > >   if (something) {
> > >     $gvar_val = "Loop GVar 1";
> > >   } elsif (somethign else) {
> > >     $gvar_val = "";
> > >   }
> > >   my $tmp;
> > >   $tmp->{loopvar} = ...;
> > >   $tmp->{gvar} = $gvar;
> > >   push @loop, $tmp;
> > > }
> > > t->param(testloop =>\@loop);
> > > 
> > > What would you expect the TMPL_LOOP to do in that example? 
> > > I would have expected that the third iteration to use the global gvar value.
> > > 
> > > Mathew
> > > 
> > > 
> > > > ========================================================================
> > > > test.tmpl:
> > > > ----------
> > > > Global Variable gvar is: <tmpl_var name=gvar>
> > > > 
> > > > Loop: <tmpl_loop name=testloop>
> > > >         loopvar: <tmpl_var name=loopvar>
> > > >         gvar   : <tmpl_var name=gvar>
> > > >       </tmpl_loop>
> > > > ========================================================================
> > > > test.pl
> > > > -------
> > > > 
> > > > use strict;
> > > > use HTML::Template;
> > > > 
> > > > my $t = new HTML::Template(filename => "test.tmpl", global_vars => 1,)
> > > > || die;
> > > > 
> > > > my $testloop = [
> > > >     { loopvar => "GVar should be set",         gvar => "Loop GVar 1" },
> > > >     { loopvar => "GVar should be blank",       gvar => ""            },
> > > >     { loopvar => "GVar should be blank again", gvar => undef         },
> > > > ];
> > > > 
> > > > $t->param(gvar     => "global variable");
> > > > $t->param(testloop => $testloop);
> > > > print $t->output();
> > > > ========================================================================
> > > > 
> > > > When you run test.pl.. you get the following output:
> > > > ------------------------------------------------------------------------
> > > > Global Variable gvar is: global variable
> > > > 
> > > > Loop: 
> > > >         loopvar: GVar should be set 
> > > >         gvar   : Loop GVar 1
> > > >       
> > > >         loopvar: GVar should be blank
> > > >         gvar   : 
> > > >       
> > > >         loopvar: GVar should be blank again
> > > >         gvar   : global variable
> > > > ------------------------------------------------------------------------
> > > > 
> > > > Now, the issue is that "gvar" in the third iteration of the loop,
> > > > "should have been blank"... i explicitely set it to "undef" in the
> > > > code.. however, since global_vars was on, it ignored my "undef". 
> > 
> > 
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

> > here you create a global variable called 'gvar'
> > > $t->param(gvar     =3D> "global variable");
> >=20
> > here you are creating a loop specific variable called 'gvar'
> > >     { loopvar =3D> "GVar should be set",         gvar =3D> "Loop =
GVar 1" },
> >=20
> > These two 'gvar's are two different variables.=20
> >=20
> > In this case
> > >     { loopvar =3D> "GVar should be blank again", gvar =3D> undef   =
      },
> >=20
> > you are saying that the loop specific 'gvar' is not part of the loop =
- ie equivalent to:
> >        { loopvar =3D> "GVar should be blank again" }
>=20
> here is where i think we differ...=20
>=20
> 1. $href =3D { loopvar =3D> "GVar should be blank again", gvar =3D> =
undef }
> to me (and in general perl programming is VERY different from:=20
> 2. $href =3D { loopvar =3D> "GVar should be blank again" }

umm... not quite... Perl treats 'unknown' and 'undef' as the same thing =
if "use strict" is in effect (which it always should be) - and this is a =
compile-time test. (Aside:  I think 'exists' on a plain scalar / =
array_ref would solve this problem - but Perl doesn't have that =
capability).

Perl will try to lookup 'gvar' in its symbol table.  If the value =
doesn't exist in the symbol table, then any use of the 'gvar' gets =
flagged as a warning - this is a run-time test.

Hash'es on the other hand, always get autovivified, thus 'exists' makes =
sense.

Relating this to TMPL_LOOP's... the question becomes, "Is a variable =
inside a loop considered to be equivalent to a hash key, or equivalent =
to a variable?", alternatively it could be asked "What is the =
'strict'ness of TMPL_LOOP variables (as compared to Perl's use of =
'strict'ness)?".
=20
> In (1), you are explicitely saying that you want "gvar" to be =
undefined.
> In (2), you are not saying that... you are effectively saying that you
> don't care what "gvar" is...

no - in (2) I said nothing about gvar - I didn't say "I dont care"
=20
> To see how perl treats them differently, here is an example of a very
> common function (keys) that returns all the keys in a hash...=20
>=20
> (1) perl  > print "Keys: ". join(',', keys %$href) . "\n";
> (1) output> Keys: gvar,loopvar
>=20
> (2) perl  > print "Keys: ". join(',', keys %$href) . "\n";
> (2) output> Keys: loopvar

Since we are talking about TMPL_LOOP variables, not Perl hash keys, it =
gets back to the question(s) posed above.

> Another example:
>=20
> -- test.pl --
> #!/usr/bin/perl
> my $tvar =3D "this is a test";
> $tvar =3D undef;
> print "Tvar=3D$tvar\n";
> -----------------------------------------
> The above prints: Tvar=3D

true - but only if you dont do:

use strict;
use warnings;

... and I cant find a single reference suggesting to not use the 'use's.


> Now, so in the same context if "undef" should mean... take the outer
> scope, then perl should have ignored my "$tvar =3D undef" line...=20

No - setting a value to 'undef' means - "remove me from the symbol =
table" - it doesnt mean, "make my value to be 'undef'" (although you get =
this behaviour if 'use strict' is not in effect).


> I think its definitely a bug :-)=20
> It has infact been flagged before as well... its partially on a thread
> at:
> =
http://www.mail-archive.com/htm...@li.../msg=
00728.html
> although that thread digressed a bit... but this topic has been bought
> up a few times... so maybe we can find more threads about it in the
> history of the list...=20

fair enough - although, that doesn't constitute a reason to modify the =
behaviour.  A change to the code, should require us to agree on the =
answer to the question(s) posed above.

Mathew


>=20
>=20
>=20
>=20
>=20
> >=20
> > thus requesting the outer global gvar to come into scope.
> >=20
> > Consider:
> >=20
> > t->param(gvar =3D> "Global gvar");
> > my $gvar_val;
> > my @loop;
> > for.... {
> >   if (something) {
> >     $gvar_val =3D "Loop GVar 1";
> >   } elsif (somethign else) {
> >     $gvar_val =3D "";
> >   }
> >   my $tmp;
> >   $tmp->{loopvar} =3D ...;
> >   $tmp->{gvar} =3D $gvar;
> >   push @loop, $tmp;
> > }
> > t->param(testloop =3D>\@loop);
> >=20
> > What would you expect the TMPL_LOOP to do in that example?=20
> > I would have expected that the third iteration to use the global =
gvar value.
> >=20
> > Mathew
> >=20
> >=20
> > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > test.tmpl:
> > > ----------
> > > Global Variable gvar is: <tmpl_var name=3Dgvar>
> > >=20
> > > Loop: <tmpl_loop name=3Dtestloop>
> > >         loopvar: <tmpl_var name=3Dloopvar>
> > >         gvar   : <tmpl_var name=3Dgvar>
> > >       </tmpl_loop>
> > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > test.pl
> > > -------
> > >=20
> > > use strict;
> > > use HTML::Template;
> > >=20
> > > my $t =3D new HTML::Template(filename =3D> "test.tmpl", =
global_vars =3D> 1,)
> > > || die;
> > >=20
> > > my $testloop =3D [
> > >     { loopvar =3D> "GVar should be set",         gvar =3D> "Loop =
GVar 1" },
> > >     { loopvar =3D> "GVar should be blank",       gvar =3D> ""      =
      },
> > >     { loopvar =3D> "GVar should be blank again", gvar =3D> undef   =
      },
> > > ];
> > >=20
> > > $t->param(gvar     =3D> "global variable");
> > > $t->param(testloop =3D> $testloop);
> > > print $t->output();
> > > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >=20
> > > When you run test.pl.. you get the following output:
> > > =
------------------------------------------------------------------------
> > > Global Variable gvar is: global variable
> > >=20
> > > Loop:=20
> > >         loopvar: GVar should be set=20
> > >         gvar   : Loop GVar 1
> > >      =20
> > >         loopvar: GVar should be blank
> > >         gvar   :=20
> > >      =20
> > >         loopvar: GVar should be blank again
> > >         gvar   : global variable
> > > =
------------------------------------------------------------------------
> > >=20
> > > Now, the issue is that "gvar" in the third iteration of the loop,
> > > "should have been blank"... i explicitely set it to "undef" in the
> > > code.. however, since global_vars was on, it ignored my "undef".=20
>=20
>=20
> 

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

> hmm... I dont consider this to be a bug...
> 
> here you create a global variable called 'gvar'
> > $t->param(gvar     => "global variable");
> 
> here you are creating a loop specific variable called 'gvar'
> >     { loopvar => "GVar should be set",         gvar => "Loop GVar 1" },
> 
> These two 'gvar's are two different variables. 
> 
> In this case
> >     { loopvar => "GVar should be blank again", gvar => undef         },
> 
> you are saying that the loop specific 'gvar' is not part of the loop - ie equivalent to:
>        { loopvar => "GVar should be blank again" }

here is where i think we differ... 

1. $href = { loopvar => "GVar should be blank again", gvar => undef }
to me (and in general perl programming is VERY different from: 
2. $href = { loopvar => "GVar should be blank again" }

In (1), you are explicitely saying that you want "gvar" to be undefined.
In (2), you are not saying that... you are effectively saying that you
don't care what "gvar" is... 

To see how perl treats them differently, here is an example of a very
common function (keys) that returns all the keys in a hash... 

(1) perl  > print "Keys: ". join(',', keys %$href) . "\n";
(1) output> Keys: gvar,loopvar

(2) perl  > print "Keys: ". join(',', keys %$href) . "\n";
(2) output> Keys: loopvar

Another example:

-- test.pl --
#!/usr/bin/perl
my $tvar = "this is a test";
$tvar = undef;
print "Tvar=$tvar\n";
-----------------------------------------
The above prints: Tvar=

Now, so in the same context if "undef" should mean... take the outer
scope, then perl should have ignored my "$tvar = undef" line... 

I think its definitely a bug :-) 
It has infact been flagged before as well... its partially on a thread
at:
http://www.mail-archive.com/htm...@li.../msg00728.html
although that thread digressed a bit... but this topic has been bought
up a few times... so maybe we can find more threads about it in the
history of the list... 

simran.








> 
> thus requesting the outer global gvar to come into scope.
> 
> Consider:
> 
> t->param(gvar => "Global gvar");
> my $gvar_val;
> my @loop;
> for.... {
>   if (something) {
>     $gvar_val = "Loop GVar 1";
>   } elsif (somethign else) {
>     $gvar_val = "";
>   }
>   my $tmp;
>   $tmp->{loopvar} = ...;
>   $tmp->{gvar} = $gvar;
>   push @loop, $tmp;
> }
> t->param(testloop =>\@loop);
> 
> What would you expect the TMPL_LOOP to do in that example? 
> I would have expected that the third iteration to use the global gvar value.
> 
> Mathew
> 
> 
> > ========================================================================
> > test.tmpl:
> > ----------
> > Global Variable gvar is: <tmpl_var name=gvar>
> > 
> > Loop: <tmpl_loop name=testloop>
> >         loopvar: <tmpl_var name=loopvar>
> >         gvar   : <tmpl_var name=gvar>
> >       </tmpl_loop>
> > ========================================================================
> > test.pl
> > -------
> > 
> > use strict;
> > use HTML::Template;
> > 
> > my $t = new HTML::Template(filename => "test.tmpl", global_vars => 1,)
> > || die;
> > 
> > my $testloop = [
> >     { loopvar => "GVar should be set",         gvar => "Loop GVar 1" },
> >     { loopvar => "GVar should be blank",       gvar => ""            },
> >     { loopvar => "GVar should be blank again", gvar => undef         },
> > ];
> > 
> > $t->param(gvar     => "global variable");
> > $t->param(testloop => $testloop);
> > print $t->output();
> > ========================================================================
> > 
> > When you run test.pl.. you get the following output:
> > ------------------------------------------------------------------------
> > Global Variable gvar is: global variable
> > 
> > Loop: 
> >         loopvar: GVar should be set 
> >         gvar   : Loop GVar 1
> >       
> >         loopvar: GVar should be blank
> >         gvar   : 
> >       
> >         loopvar: GVar should be blank again
> >         gvar   : global variable
> > ------------------------------------------------------------------------
> > 
> > Now, the issue is that "gvar" in the third iteration of the loop,
> > "should have been blank"... i explicitely set it to "undef" in the
> > code.. however, since global_vars was on, it ignored my "undef". 

Re: [htmltmpl] Coding up a three column table...

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

if you are using H::T::E you can leave your output formatting to the =
template, and leave your Perl code as a single loop (with no embedded =
loops). eg:

my @loop;
for ... {
  push @loop, something;
}
$t->param(loop =3D> \@loop);


<!-- want 3 columns -->

<table ...>
   <TMPL_LOOP loop>
      <TMPL_IF EXPR=3D"(__counter % 3) =3D=3D 1">
         <tr>
      </TMPL_IF>

            <td>
                 <TMPL_VAR blah>
            </td>
      <TMPL_IF EXPR=3D"(__counter % 3) =3D=3D 0">
         </tr>
      </TMPL_IF>
   </TMPL_LOOP>
</table>

In this example, the formatting out the HTML is completly in the hands =
of the template -> the Perl code need not know anything about how the =
array will get displayed.

Mathew

PS.  I use it to make a 3-column display of an image gallery - =
http://www.lrautomotive.com.au/gallery.html

> I've got an image gallery that I want displayed as three columns.
>=20
> Am I right in assuming that I need to code it up as an array of rows
> containing the array of the column cells?
>=20
> Anyone got any nice idiomatic perl for transforming a simple array
> into one of these? ;-)
>=20
> Ta,
>=20
> Dave
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to=20
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=3Dosdnemail3
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

Re: [htmltmpl] Patch to fix global_vars and loop problem...

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

hmm... I dont consider this to be a bug...

here you create a global variable called 'gvar'
> $t->param(gvar     =3D> "global variable");

here you are creating a loop specific variable called 'gvar'
>     { loopvar =3D> "GVar should be set",         gvar =3D> "Loop GVar =
1" },

These two 'gvar's are two different variables.=20

In this case
>     { loopvar =3D> "GVar should be blank again", gvar =3D> undef       =
  },

you are saying that the loop specific 'gvar' is not part of the loop - =
ie equivalent to:
       { loopvar =3D> "GVar should be blank again" }

thus requesting the outer global gvar to come into scope.

Consider:

t->param(gvar =3D> "Global gvar");
my $gvar_val;
my @loop;
for.... {
  if (something) {
    $gvar_val =3D "Loop GVar 1";
  } elsif (somethign else) {
    $gvar_val =3D "";
  }
  my $tmp;
  $tmp->{loopvar} =3D ...;
  $tmp->{gvar} =3D $gvar;
  push @loop, $tmp;
}
t->param(testloop =3D>\@loop);

What would you expect the TMPL_LOOP to do in that example?=20
I would have expected that the third iteration to use the global gvar =
value.

Mathew


> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> test.tmpl:
> ----------
> Global Variable gvar is: <tmpl_var name=3Dgvar>
>=20
> Loop: <tmpl_loop name=3Dtestloop>
>         loopvar: <tmpl_var name=3Dloopvar>
>         gvar   : <tmpl_var name=3Dgvar>
>       </tmpl_loop>
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> test.pl
> -------
>=20
> use strict;
> use HTML::Template;
>=20
> my $t =3D new HTML::Template(filename =3D> "test.tmpl", global_vars =
=3D> 1,)
> || die;
>=20
> my $testloop =3D [
>     { loopvar =3D> "GVar should be set",         gvar =3D> "Loop GVar =
1" },
>     { loopvar =3D> "GVar should be blank",       gvar =3D> ""          =
  },
>     { loopvar =3D> "GVar should be blank again", gvar =3D> undef       =
  },
> ];
>=20
> $t->param(gvar     =3D> "global variable");
> $t->param(testloop =3D> $testloop);
> print $t->output();
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> When you run test.pl.. you get the following output:
> =
------------------------------------------------------------------------
> Global Variable gvar is: global variable
>=20
> Loop:=20
>         loopvar: GVar should be set=20
>         gvar   : Loop GVar 1
>      =20
>         loopvar: GVar should be blank
>         gvar   :=20
>      =20
>         loopvar: GVar should be blank again
>         gvar   : global variable
> =
------------------------------------------------------------------------
>=20
> Now, the issue is that "gvar" in the third iteration of the loop,
> "should have been blank"... i explicitely set it to "undef" in the
> code.. however, since global_vars was on, it ignored my "undef".=20

Re: [htmltmpl] stderr from script: &Digest::MD5::md5_hex function...

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

On Wed, 12 May 2004, Kapoor, Nishikant wrote:

> [Wed May 12 08:16:00 2004] [error] [client 127.0.0.1] stderr from =
> script: &Digest::MD5::md5_hex function probably called as class method =
> at HTML/Template.pm line 1231.
>
> I checked the line 1231 in Template.pm and it says:
>
>   my $hash =3D Digest::MD5->md5_hex($filepath);

You can ignore that warning.  I'm guessing it was added in a newer
version of Digest::MD5 since I've never seen it.  I guess I should be
calling md5_hex() as a function rather than as a class method.

-sam

[htmltmpl] stderr from script: &Digest::MD5::md5_hex function...

[Kapoor, N. <nis...@xc...>]

I just turned ON file_cache today and it started giving following =
message in apache logs. Could anyone please explain what it actually =
means? The cache files seemed to be getting generated though.

[Wed May 12 08:16:00 2004] [error] [client 127.0.0.1] stderr from =
script: &Digest::MD5::md5_hex function probably called as class method =
at HTML/Template.pm line 1231.

I checked the line 1231 in Template.pm and it says:

  my $hash =3D Digest::MD5->md5_hex($filepath);

I am using H::T v2.5, perl v5.8.1 on Mandrake 9.2.

Thanks
Nishi

Re: [htmltmpl] warning_on_bad_params (fwd)

[Karen J. C. <si...@ph...>]

On Wed, 12 May 2004, Gabor Szabo wrote:

GS>You mean I can do it with only http access to that server ?

Well, that depends on how secure the server is.  Heh.  Properly, no.

GS>Even the other guy has only simple user ssh access and he cannot change
GS>the configuration of the web server.

But can he create a new instance of the server with a different config?
Might be adequate.  I run the test server on my own machine with only my
own (normal-user) access.

-- 
Karen J. Cravens  si...@ph...

Re: [htmltmpl] Coding up a three column table...

[Benjamin W. <war...@sb...>]

On Wed, 12 May 2004, Carl Franks wrote:

> my $cols = 3;
> 
> my @foo = ({one => 1, ein => 1},    {two => 2, zwei => 2}, 
>            {three => 3, drei => 3}, {four => 4, vier => 4});
> my @bar;

From here, wouldn't it be simpler to use splice?

  push @bar, [splice @foo,0,$cols] while @foo;

It has the disadvantage of being destructive of @foo, but it's ever so 
much easier on the eyes (well, my eyes, anyway).

And then once you have the 2D array of rows, you'll need (unless this 
feature's crept in while I wasn't looking) to transform it to an array of 
hashrefs with the sub-loop under the appropriate key:

  $tmpl->param( loop => [ map +{subloop => $_}, @bar ]);

This puts me in mind of a feature I was once planning to either ask for or
attempt to produce (and may yet): some analog to $_ for HTML::Template
loops.  I don't know how common a situation is is, but loops with exactly
one parameter (be it a sub-loop or a single TMPL_VAR) seem to occur
frequently in my (relatively limited) use of H::T.  Being able to use
something like <TMPL_VAR _ > and pass an arrayref to param() instead of
mapping it to an AoH would produce a small but measurable improvement in
my quality of life.  Is this something that's been looked at before and
decided against, or would it be worth contemplating next time I have
coding time on my hands?

	--Ben

-- 
Eat drink and be merry!  Tomorrow you may be in Utah.