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

[htmltmpl] HTML::Template - need to merge the columns of a table

[Senthil N. <rs...@gm...>]

Hi All,

I need to merge the columns of a table during runtime in HTNL Template.

I have a bool variable set, whenever the cells needs to be merged.
So, chking for that var if its set, need to merge the cells else need to
have the cells as defined earlier.

How this can be done in HTML::Template??

Thanks
Senthil

[htmltmpl] Re: mod_perl and HTML::Template issues - RESOLVED

[Senthil N. <rs...@gm...>]

I resolved this problem and only the global variables is the issue.

I changed all the global variables to be passed as arguments to the other
functions and this resolved my problem.

Hope this will be useful to other guys working on MOD_PERL

Thanks
Senthil

On 12/14/05, Senthil Nathan <rs...@gm...> wrote:
>
> Hi All,
>
> I faced problems using mod_perl and HTML::Template.
>
> The rows displayed using HTML::Template gets duplicated on every reload o=
f
> the page developed using CGI/Perl only in mod_perl environment.
>
> Otherwise its displayed properly.
>
> I understand that its a global variable problem with mod_perl. But Have
> anyone faced this problem and resolved this.
>
> Thanks
> Senthil
>

[htmltmpl] mod_perl and HTML::Template issues

[Senthil N. <rs...@gm...>]

Hi All,

I faced problems using mod_perl and HTML::Template.

The rows displayed using HTML::Template gets duplicated on every reload of
the page developed using CGI/Perl only in mod_perl environment.

Otherwise its displayed properly.

I understand that its a global variable problem with mod_perl. But Have
anyone faced this problem and resolved this.

Thanks
Senthil

Re: [htmltmpl] Speed loss with parameters global_vars and loop_context_vars

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

* Oli...@t-... <Oli...@t-...> [December 14 2005, 15:00]:
> I coded a site with an outer loop, an inner loop and an inner inner loop. global_vars and loop_context_vars were on.  
>  
> I was wondering about the time the output of this site lasts: 14 seconds ! After this I turned gobal_vars and loop_context_vars off and was wondering again: the output was processed after 1.5 seconds. 
>  
> I wrote a simplified Example (see below) and got the following results on my system: 
> global_vars=1, loop_context_vars=1: 2.4 seconds 
> global_vars=1, loop_context_vars=0: 5.7 seconds 
> global_vars=0, loop_context_vars=1: 5.7 seconds 
> global_vars=1, loop_context_vars=1: 13.0 seconds !!! 
>  
> So here is my question: Is this behavior normal ? 

  Yes. HTML::Template global_vars are very inefficient.

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

[htmltmpl] Speed loss with parameters global_vars and loop_context_vars

[<Oli...@t-...>]

I coded a site with an outer loop, an inner loop and an inner inner loop. global_vars and loop_context_vars were on.  
 
I was wondering about the time the output of this site lasts: 14 seconds ! After this I turned gobal_vars and loop_context_vars off and was wondering again: the output was processed after 1.5 seconds. 
 
I wrote a simplified Example (see below) and got the following results on my system: 
global_vars=1, loop_context_vars=1: 2.4 seconds 
global_vars=1, loop_context_vars=0: 5.7 seconds 
global_vars=0, loop_context_vars=1: 5.7 seconds 
global_vars=1, loop_context_vars=1: 13.0 seconds !!! 
 
So here is my question: Is this behavior normal ? 
 

Example: Please toggle the values of global_vars and loop_context_vars to see the difference. 


html_tmpl.pl--------------------------------------------- 
#!/usr/bin/perl -w 
 
use HTML::Template; 
use Time::HiRes qw(gettimeofday); 
 
my $inner_loop; 
for(my $i=0; $i<500; $i++) { 
  my $inner_inner_loop; 
  for(my $dat=1; $dat<=12; $dat++) { 
    push(@$inner_inner_loop, {'data' => $dat}); 
  } 
  push(@$inner_loop, { 'inner_inner_loop' => $inner_inner_loop }); 
} 
 
my $outer_loop; 
push(@$outer_loop, {'inner_loop' => $inner_loop}); 
 
my $tmpl = HTML::Template->new(filename=>'html_tmpl.tmpl', global_vars=>1, loop_context_vars=>0); 
$tmpl->param('outer_loop' => $outer_loop); 
 
my $t0 = gettimeofday; 
my $output = $tmpl->output(); 
my $t1 = gettimeofday; 
print $t1-$t0; 
------------------------------------------------------ 


html_tmpl.tmpl---------------------------------------- 
<tmpl_loop name="outer_loop"> 
  <tmpl_loop name="inner_loop"> 
    <tmpl_loop name="inner_inner_loop"> 
      <tmpl_var name="data">
    </tmpl_loop>
  </tmpl_loop> 
</tmpl_loop> 

[htmltmpl] Re: HTML::Template and XHTML

[Mark S. <ma...@su...>]

On 2005-10-28, Chris Beck <htm...@pa...> wrote:
> Rumour has it Mathew Robertson, on or about 25.Oct.2005 19:48, whispered:
>> you can do this with a filter:
>> 
>> my $match = qr/(<[Tt][Mm][Pp][Ll]_[^>]+)\/>/;
>> my $filter = sub {
>>  my $text_ref = shift;
>>  $$text_ref =~ s/$match/$1>/g;
>> };
>
> Hi Mathew, thanks for the help.  I am already using filters so I can embed tags
> in form fields.  I was just hoping for a new XHTML aware version :)

Even if HTML::Template supported this, <tmpl_var> is not a valid XHTML
tag.  Did you have another part to your solution that would solve that
aspect? 

It seems like it would necessary to teach your other tools about this as
well.

    Mark

-- 
http://mark.stosberg.com/ 

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

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

As a thought, you could try something like this:

print Dumper($ht->{param_map});

I haven't tested it, but it may work...
Mathew

Boon Chew wrote:

>Thanks Carl, useful tip.  Taking your idea one step
>further, I think having an option such as
>
>show_all_params =3D> 1 that shows all the params passed
>to the template in a Dumper fashion will be quite
>useful.
>
>
>- boon
>
>--- Carl Franks <fir...@gm...> wrote:
>
> =20
>
>>If you make sure
>>die_on_bad_params =3D> 1
>>is set in your HTML::Template constructor, then any
>>variable which
>>isn't set in the template, or is misspelt will cause
>>the page to die -
>>the designer can then tell what's wrong by simply
>>looking at the error
>>message.
>>
>>Carl
>>
>>
>>On 02/12/05, Boon Chew <was...@ya...> wrote:
>>   =20
>>
>>>Well, I guess I should have explained the need of
>>>     =20
>>>
>>this
>>   =20
>>
>>>with a more solid real world use case.
>>>Recently I am involved in a project using Krang, a
>>>     =20
>>>
>>CMS
>>   =20
>>
>>>system written in Perl that utilizes
>>>     =20
>>>
>>HTML::Template.
>>   =20
>>
>>>Now here is the thing, we are fairly new to the
>>>     =20
>>>
>>code
>>   =20
>>
>>>base, but in a few days of going through the code
>>>     =20
>>>
>>and
>>   =20
>>
>>>poking around the code, we were able to implement
>>>quite a few new features for the client.
>>>
>>>But our understanding of the system is still
>>>     =20
>>>
>>immature
>>   =20
>>
>>>and incomplete, and there are times the template
>>>     =20
>>>
>>var
>>   =20
>>
>>>is being set somewhere in the inheritance chain,
>>>     =20
>>>
>>and
>>   =20
>>
>>>we know a template can access a specific variable
>>>(through incomplete doc and tmpl_if test), but
>>>     =20
>>>
>>there
>>   =20
>>
>>>is no way to know how to access the variable
>>>     =20
>>>
>>without
>>   =20
>>
>>>going through the code tracing out where and what
>>>     =20
>>>
>>is
>>   =20
>>
>>>sent to the template.  And what if the
>>>     =20
>>>
>>documentation
>>   =20
>>
>>>misses talking about a var that is sent to the
>>>template?  No one you can find out unless you poke
>>>around the code, but the process can be time
>>>     =20
>>>
>>consuming
>>   =20
>>
>>>as not all the templates are being set in one file
>>>(due to OO).
>>>
>>>I find it surprising that people expect problems
>>>     =20
>>>
>>can
>>   =20
>>
>>>be solved with documentation, or communication
>>>     =20
>>>
>>with
>>   =20
>>
>>>the frontend folks.  In the real world,
>>>     =20
>>>
>>documentation
>>   =20
>>
>>>is never as complete as should, I mean, it's hard
>>>enough to get some to comment their code!  And in
>>>     =20
>>>
>>the
>>   =20
>>
>>>real world, you don't always start a project with
>>>     =20
>>>
>>code
>>   =20
>>
>>>that you have written as well.  The need to be
>>>     =20
>>>
>>able to
>>   =20
>>
>>>introspect and access what is sent to the template
>>>without having the perl code is a useful and
>>>justifiable feature of any server-side scripting
>>>framework.
>>>
>>>
>>>- boon
>>>
>>>--- "Webmaster Techcode.NET"
>>>     =20
>>>
>><web...@te...>
>>   =20
>>
>>>wrote:
>>>
>>>     =20
>>>
>>>>----- Original Message -----
>>>>From: Boon Chew
>>>>
>>>>I want a way to quickly display all the info in
>>>>       =20
>>>>
>>a
>>   =20
>>
>>>>var - a Dumper output if you will.  But more
>>>>       =20
>>>>
>>than
>>   =20
>>
>>>>that, like in some other server-side language,
>>>>       =20
>>>>
>>you
>>   =20
>>
>>>>can query the column lists (or hash keys) and
>>>>       =20
>>>>
>>loop
>>   =20
>>
>>>>through those and use a piece of generic code
>>>>       =20
>>>>
>>when
>>   =20
>>
>>>>all you intend to do is to display everything in
>>>>       =20
>>>>
>>the
>>   =20
>>
>>>>var.
>>>>
>>>>----- Original Message -----
>>>>
>>>>I agree - something like Data::Dumper in
>>>>HTML::Template context would be great.
>>>>
>>>>And you can also "you can query the column lists
>>>>       =20
>>>>
>>(or
>>   =20
>>
>>>>hash keys) and loop through those" in Perl just
>>>>       =20
>>>>
>>like
>>   =20
>>
>>>>in any other server-side language ...
>>>>
>>>>foreach(@array){
>>>>    print $_,"\n<br>";
>>>>}
>>>>
>>>>
>>>>
>>>>----- Original Message -----
>>>>The tight coupling of knowledge between what's
>>>>       =20
>>>>
>>being
>>   =20
>>
>>>>sent from the perl code and the HTML can be
>>>>       =20
>>>>
>>avoided,
>>   =20
>>
>>>>that's the whole point of the design of the
>>>>       =20
>>>>
>>template
>>   =20
>>
>>>>module (vs Mason where you mingle Perl code with
>>>>display code) right?  It just seems ugly when I
>>>>       =20
>>>>
>>have
>>   =20
>>
>>>>to tell a designer to go look at the perl file
>>>>       =20
>>>>
>>to
>>   =20
>>
>>>>see what he is getting in the var.  He should be
>>>>able to find that out fro m some sensible
>>>>constructs.
>>>>----- Original Message -----
>>>>
>>>>You missed the point ...
>>>>
>>>>I mean - designer shouldn't need to take a look
>>>>       =20
>>>>
>>at
>>   =20
>>
>>>>Perl code to figure out what you are outputing
>>>>       =20
>>>>
>>...
>>   =20
>>
>>>>And "some sensible constructs" are documents
>>>>       =20
>>>>
>>that
>>   =20
>>
>>>>folow every project. Have you ever heared of
>>>>       =20
>>>>
>>terms
>>   =20
>>
>>>>like API or Interface? You and you designer need
>>>>       =20
>>>>
>>to
>>   =20
>>
>>>>agree on "Interface" - in your case the data he
>>>>       =20
>>>>
>>can
>>   =20
>>
>>>>use in the template ...
>>>>
>>>>Anyway - the quick and simple solution that just
>>>>crossed my mind ;)
>>>>
>>>>Make something a rule - for each template - you
>>>>could create a special variable. Say you can
>>>>       =20
>>>>
>>name it
>>   =20
>>
>>>>: "the_dump" or whatever.
>>>>And simply dump via Data::Dumper all variables
>>>>       =20
>>>>
>>that
>>   =20
>>
>>>>you (plan) populate the template with - or send
>>>>       =20
>>>>
>>to
>>   =20
>>
>>>>template.
>>>>
>>>>Actualy - this could be made as part of
>>>>HTML-Template ...
>>>>
>>>>Anyway - then your designer could just add
>>>>       =20
>>>>
>><tmpl_var
>>   =20
>>
>>>>name=3D"the_dump"> at the end of the template if
>>>>       =20
>>>>
>>he is
>>   =20
>>
>>>>not sure what data he can access.
>>>>
>>>>Of course - next thing he will complain is why
>>>>       =20
>>>>
>>in
>>   =20
>>
>>>>the hell he can't do a preview in Dreamweaver
>>>>       =20
>>>>
>>with
>>   =20
>>
>>>>test data already populated ...
>>>>
>>>>Cheers,
>>>>Alex.
>>>>N=18=ACHY=DE=B5=E9s(S(X=AC=B2s('=B2S(=DEu=BC'=A6[=A7?0/00=DC=0EOE=A8=BA=

>>>>=DE=A6=D8k=A2=E8!-^=1FS(W=AC~S(=E9(r)+=E5zk=12=B6S(C=A3
>>>>       =20
>>>>
>=E5=A1=A7m...=E9=DE=C0=02@^=C7s(=AD=C8^z(=08=A7z=D8Z=B6f=A4z=CB=1Ej=B7!S=
(x2=A2=EA=E5=A2=07=E2.=EB=1A=B1=E6=AC=C9=AB,=BA=B7=E2z(=0Ba{=07>=0C=E5?,=E0=
=03H=F2=D44=A8m=B6Y"=FFi=DB(=B1=D9=DC=A2o=DAv'=EF=AD=FBjYhr'=D7=AF:=E6S(r=
Xoe?{f-=D7=A6=A6V=ADz=EB=1E(r)=C9s(S(X=A7,X=AC=B4{f-=D7=A6=A6V=ADz=EB=1E(=
r)=C9b=B2=DB,=A2=EA=DCy=FA+?=E9=DE=B6=1Bm=A6=CF=FF-+-=B2=CA.=AD=C7Y"=A2=B8=
=1E?=EB?-+-=B3=F9b=B2=D8=A7~?=E1=B6imzjej=D7(r)=B1=EA=EC
> =20
>
>>>
>>>
>>>__________________________________________
>>>Yahoo! DSL - Something to write home about.
>>>Just $16.99/mo. or less.
>>>dsl.yahoo.com
>>>
>>>
>>>
>>>
>>>     =20
>>>
>-------------------------------------------------------
> =20
>
>>>This SF.net email is sponsored by: Splunk Inc. Do
>>>     =20
>>>
>>you grep through log files
>>   =20
>>
>>>for problems?  Stop!  Download the new AJAX search
>>>     =20
>>>
>>engine that makes
>>   =20
>>
>>>searching your log files as easy as surfing the=20
>>>     =20
>>>
>>web.  DOWNLOAD SPLUNK!
>>   =20
>>
>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> =20
>
>>>_______________________________________________
>>>Html-template-users mailing list
>>>     =20
>>>
>=3D=3D=3D message truncated =3D=3D=3D
>
>
>
>	=09
>__________________________________=20
>Start your day with Yahoo! - Make it your home page!=20
>http://www.yahoo.com/r/hs
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users
> =20
>

[htmltmpl] Re: is it possible to use var in include

[Mark S. <ma...@su...>]

On 2005-09-28, mic...@cs... <mic...@cs...> wrote:
> Dies ist eine mehrteilige Nachricht im MIME-Format.
> --=_alternative 004DED9DC125708A_=
> Content-Type: text/plain; charset="US-ASCII"
>
> Hello all,
>
> Is that not possible? <TMPL_INCLUDE NAME=<TMPL_VAR NAME=mod>>
> Cause depending in which mode I open the template I want to show up a 
> differnt body (e.g. start page, register page, search page...)

This is supported in HTML::Template::Compiled as:

 <TMPL_INCLUDE VAR="mod">

However, I can only say that from reading the docs. I haven't used the module
yet myself and can't directly vouch for it.

    Mark

[htmltmpl] (no subject)

[<ig...@sh...>]

htm...@li...
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.3
X-Originating-IP: 200.125.117.107

Hi,
I think your problem is about mod_perl, and not HTML::Template.

you must use strict and reset your global variables.

On Tuesday 06 December 2005 11:25, Senthil Nathan wrote:
> Hi All,
>
> Im using mod_perl 2 on Apache 2. I am using HTML::Template to display the
> data from the perl/cgi script.
>
> For the first time loading the data is displayed properly. then for every
> reload the data displayed on the template gets repeatedly displayed. (i.e,
> it gets accumulated. for 5 times reload 5 sets of data is displayed in the
> template).
>
> Actually this problem is not seen on cgi/perl environment. Only with
> mod_perl this problem occurs.
>
> As this is also related with HTML::Template i posted it here.
>
> Thanks
> Senthil

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[htmltmpl] mod_perl and html::template issues - data gets repeated on every reload

[Senthil N. <rs...@gm...>]

Hi All,

Im using mod_perl 2 on Apache 2. I am using HTML::Template to display the
data from the perl/cgi script.

For the first time loading the data is displayed properly. then for every
reload the data displayed on the template gets repeatedly displayed. (i.e,
it gets accumulated. for 5 times reload 5 sets of data is displayed in the
template).

Actually this problem is not seen on cgi/perl environment. Only with
mod_perl this problem occurs.

As this is also related with HTML::Template i posted it here.

Thanks
Senthil

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Boon C. <was...@ya...>]

Thanks Carl, useful tip.  Taking your idea one step
further, I think having an option such as

show_all_params => 1 that shows all the params passed
to the template in a Dumper fashion will be quite
useful.


- boon

--- Carl Franks <fir...@gm...> wrote:

> If you make sure
> die_on_bad_params => 1
> is set in your HTML::Template constructor, then any
> variable which
> isn't set in the template, or is misspelt will cause
> the page to die -
> the designer can then tell what's wrong by simply
> looking at the error
> message.
> 
> Carl
> 
> 
> On 02/12/05, Boon Chew <was...@ya...> wrote:
> >
> > Well, I guess I should have explained the need of
> this
> > with a more solid real world use case.
> > Recently I am involved in a project using Krang, a
> CMS
> > system written in Perl that utilizes
> HTML::Template.
> > Now here is the thing, we are fairly new to the
> code
> > base, but in a few days of going through the code
> and
> > poking around the code, we were able to implement
> > quite a few new features for the client.
> >
> > But our understanding of the system is still
> immature
> > and incomplete, and there are times the template
> var
> > is being set somewhere in the inheritance chain,
> and
> > we know a template can access a specific variable
> > (through incomplete doc and tmpl_if test), but
> there
> > is no way to know how to access the variable
> without
> > going through the code tracing out where and what
> is
> > sent to the template.  And what if the
> documentation
> > misses talking about a var that is sent to the
> > template?  No one you can find out unless you poke
> > around the code, but the process can be time
> consuming
> > as not all the templates are being set in one file
> > (due to OO).
> >
> > I find it surprising that people expect problems
> can
> > be solved with documentation, or communication
> with
> > the frontend folks.  In the real world,
> documentation
> > is never as complete as should, I mean, it's hard
> > enough to get some to comment their code!  And in
> the
> > real world, you don't always start a project with
> code
> > that you have written as well.  The need to be
> able to
> > introspect and access what is sent to the template
> > without having the perl code is a useful and
> > justifiable feature of any server-side scripting
> > framework.
> >
> >
> > - boon
> >
> > --- "Webmaster Techcode.NET"
> <web...@te...>
> > wrote:
> >
> > >
> > > ----- Original Message -----
> > > From: Boon Chew
> > >
> > > I want a way to quickly display all the info in
> a
> > > var - a Dumper output if you will.  But more
> than
> > > that, like in some other server-side language,
> you
> > > can query the column lists (or hash keys) and
> loop
> > > through those and use a piece of generic code
> when
> > > all you intend to do is to display everything in
> the
> > > var.
> > >
> > > ----- Original Message -----
> > >
> > > I agree - something like Data::Dumper in
> > > HTML::Template context would be great.
> > >
> > > And you can also "you can query the column lists
> (or
> > > hash keys) and loop through those" in Perl just
> like
> > > in any other server-side language ...
> > >
> > > foreach(@array){
> > >     print $_,"\n<br>";
> > > }
> > >
> > >
> > >
> > > ----- Original Message -----
> > > The tight coupling of knowledge between what's
> being
> > > sent from the perl code and the HTML can be
> avoided,
> > > that's the whole point of the design of the
> template
> > > module (vs Mason where you mingle Perl code with
> > > display code) right?  It just seems ugly when I
> have
> > > to tell a designer to go look at the perl file
> to
> > > see what he is getting in the var.  He should be
> > > able to find that out fro m some sensible
> > > constructs.
> > > ----- Original Message -----
> > >
> > > You missed the point ...
> > >
> > > I mean - designer shouldn't need to take a look
> at
> > > Perl code to figure out what you are outputing
> ...
> > > And "some sensible constructs" are documents
> that
> > > folow every project. Have you ever heared of
> terms
> > > like API or Interface? You and you designer need
> to
> > > agree on "Interface" - in your case the data he
> can
> > > use in the template ...
> > >
> > > Anyway - the quick and simple solution that just
> > > crossed my mind ;)
> > >
> > > Make something a rule - for each template - you
> > > could create a special variable. Say you can
> name it
> > > : "the_dump" or whatever.
> > > And simply dump via Data::Dumper all variables
> that
> > > you (plan) populate the template with - or send
> to
> > > template.
> > >
> > > Actualy - this could be made as part of
> > > HTML-Template ...
> > >
> > > Anyway - then your designer could just add
> <tmpl_var
> > > name="the_dump"> at the end of the template if
> he is
> > > not sure what data he can access.
> > >
> > > Of course - next thing he will complain is why
> in
> > > the hell he can't do a preview in Dreamweaver
> with
> > > test data already populated ...
> > >
> > > Cheers,
> > > Alex.
> > > N¬HY޵隊X¬²š'²ŠÞu¼'¦[§?‰ÜŒ¨º
> > > Þ¦Øk¢è!–ˆŠW¬~Šé(r)†åzk¶ŠC£
> >
>
塧m…éÞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å?,àHòÔ4¨m¶ŸÿiÛ(±ÙÜ¢oÚv'ï­ûjYhr'ׯ:æŠrXœ?{f–צ¦V­zë(r)ɚŠX§‚X¬´{f–צ¦V­zë(r)Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸?ë–+-³ùb²Ø§~?á¶imzjej×(r)±êì
> >
> >
> >
> >
> > __________________________________________
> > Yahoo! DSL – Something to write home about.
> > Just $16.99/mo. or less.
> > dsl.yahoo.com
> >
> >
> >
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do
> you grep through log files
> > for problems?  Stop!  Download the new AJAX search
> engine that makes
> > searching your log files as easy as surfing the 
> web.  DOWNLOAD SPLUNK!
> >
>
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Html-template-users mailing list
> 
=== message truncated ===



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Octavian R. <ora...@fc...>]

From: "Carl Franks" <fir...@gm...>

> If you make sure
> die_on_bad_params => 1
> is set in your HTML::Template constructor, then any variable which
> isn't set in the template, or is misspelt will cause the page to die -
> the designer can then tell what's wrong by simply looking at the error
> message.
>
> Carl
>


This is not always simple.
Sometimes the error says only something like... that the variable "id" is
not present in the template file.
But if I take a look in the main program, I see that there is no "id"
defined with:

$ht->param(id => $id);

Usually the key "id" is included in another variable but this is not very
easy to find, because that variable might be returned by a separate module,
and I don't even know in which variable is defined that "id" key.
Maybe more variables which are returned by the modules contain an "id" field
but I don't know which of them is wrong.

It would be more helpful if H::T would also say (in that error) the name of
the loop that created the error. In that case it would be more simple to
find the variable which has some bad keys in it.

But if die_on_bad_params => 0, will this make T::H work slower?
I have some modules that return more variables than I need in a certain
template because I need them in other templates or programs, and I don't
want to create more if() statements or more variables in order to send just
the needed vars, so I usually prefer sending more variables than the
template files need.


Thanks.

Teddy

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Carl F. <fir...@gm...>]

SWYgeW91IG1ha2Ugc3VyZQpkaWVfb25fYmFkX3BhcmFtcyA9PiAxCmlzIHNldCBpbiB5b3VyIEhU
TUw6OlRlbXBsYXRlIGNvbnN0cnVjdG9yLCB0aGVuIGFueSB2YXJpYWJsZSB3aGljaAppc24ndCBz
ZXQgaW4gdGhlIHRlbXBsYXRlLCBvciBpcyBtaXNzcGVsdCB3aWxsIGNhdXNlIHRoZSBwYWdlIHRv
IGRpZSAtCnRoZSBkZXNpZ25lciBjYW4gdGhlbiB0ZWxsIHdoYXQncyB3cm9uZyBieSBzaW1wbHkg
bG9va2luZyBhdCB0aGUgZXJyb3IKbWVzc2FnZS4KCkNhcmwKCgpPbiAwMi8xMi8wNSwgQm9vbiBD
aGV3IDx3YXNwZmlzaEB5YWhvby5jb20+IHdyb3RlOgo+Cj4gV2VsbCwgSSBndWVzcyBJIHNob3Vs
ZCBoYXZlIGV4cGxhaW5lZCB0aGUgbmVlZCBvZiB0aGlzCj4gd2l0aCBhIG1vcmUgc29saWQgcmVh
bCB3b3JsZCB1c2UgY2FzZS4KPiBSZWNlbnRseSBJIGFtIGludm9sdmVkIGluIGEgcHJvamVjdCB1
c2luZyBLcmFuZywgYSBDTVMKPiBzeXN0ZW0gd3JpdHRlbiBpbiBQZXJsIHRoYXQgdXRpbGl6ZXMg
SFRNTDo6VGVtcGxhdGUuCj4gTm93IGhlcmUgaXMgdGhlIHRoaW5nLCB3ZSBhcmUgZmFpcmx5IG5l
dyB0byB0aGUgY29kZQo+IGJhc2UsIGJ1dCBpbiBhIGZldyBkYXlzIG9mIGdvaW5nIHRocm91Z2gg
dGhlIGNvZGUgYW5kCj4gcG9raW5nIGFyb3VuZCB0aGUgY29kZSwgd2Ugd2VyZSBhYmxlIHRvIGlt
cGxlbWVudAo+IHF1aXRlIGEgZmV3IG5ldyBmZWF0dXJlcyBmb3IgdGhlIGNsaWVudC4KPgo+IEJ1
dCBvdXIgdW5kZXJzdGFuZGluZyBvZiB0aGUgc3lzdGVtIGlzIHN0aWxsIGltbWF0dXJlCj4gYW5k
IGluY29tcGxldGUsIGFuZCB0aGVyZSBhcmUgdGltZXMgdGhlIHRlbXBsYXRlIHZhcgo+IGlzIGJl
aW5nIHNldCBzb21ld2hlcmUgaW4gdGhlIGluaGVyaXRhbmNlIGNoYWluLCBhbmQKPiB3ZSBrbm93
IGEgdGVtcGxhdGUgY2FuIGFjY2VzcyBhIHNwZWNpZmljIHZhcmlhYmxlCj4gKHRocm91Z2ggaW5j
b21wbGV0ZSBkb2MgYW5kIHRtcGxfaWYgdGVzdCksIGJ1dCB0aGVyZQo+IGlzIG5vIHdheSB0byBr
bm93IGhvdyB0byBhY2Nlc3MgdGhlIHZhcmlhYmxlIHdpdGhvdXQKPiBnb2luZyB0aHJvdWdoIHRo
ZSBjb2RlIHRyYWNpbmcgb3V0IHdoZXJlIGFuZCB3aGF0IGlzCj4gc2VudCB0byB0aGUgdGVtcGxh
dGUuICBBbmQgd2hhdCBpZiB0aGUgZG9jdW1lbnRhdGlvbgo+IG1pc3NlcyB0YWxraW5nIGFib3V0
IGEgdmFyIHRoYXQgaXMgc2VudCB0byB0aGUKPiB0ZW1wbGF0ZT8gIE5vIG9uZSB5b3UgY2FuIGZp
bmQgb3V0IHVubGVzcyB5b3UgcG9rZQo+IGFyb3VuZCB0aGUgY29kZSwgYnV0IHRoZSBwcm9jZXNz
IGNhbiBiZSB0aW1lIGNvbnN1bWluZwo+IGFzIG5vdCBhbGwgdGhlIHRlbXBsYXRlcyBhcmUgYmVp
bmcgc2V0IGluIG9uZSBmaWxlCj4gKGR1ZSB0byBPTykuCj4KPiBJIGZpbmQgaXQgc3VycHJpc2lu
ZyB0aGF0IHBlb3BsZSBleHBlY3QgcHJvYmxlbXMgY2FuCj4gYmUgc29sdmVkIHdpdGggZG9jdW1l
bnRhdGlvbiwgb3IgY29tbXVuaWNhdGlvbiB3aXRoCj4gdGhlIGZyb250ZW5kIGZvbGtzLiAgSW4g
dGhlIHJlYWwgd29ybGQsIGRvY3VtZW50YXRpb24KPiBpcyBuZXZlciBhcyBjb21wbGV0ZSBhcyBz
aG91bGQsIEkgbWVhbiwgaXQncyBoYXJkCj4gZW5vdWdoIHRvIGdldCBzb21lIHRvIGNvbW1lbnQg
dGhlaXIgY29kZSEgIEFuZCBpbiB0aGUKPiByZWFsIHdvcmxkLCB5b3UgZG9uJ3QgYWx3YXlzIHN0
YXJ0IGEgcHJvamVjdCB3aXRoIGNvZGUKPiB0aGF0IHlvdSBoYXZlIHdyaXR0ZW4gYXMgd2VsbC4g
IFRoZSBuZWVkIHRvIGJlIGFibGUgdG8KPiBpbnRyb3NwZWN0IGFuZCBhY2Nlc3Mgd2hhdCBpcyBz
ZW50IHRvIHRoZSB0ZW1wbGF0ZQo+IHdpdGhvdXQgaGF2aW5nIHRoZSBwZXJsIGNvZGUgaXMgYSB1
c2VmdWwgYW5kCj4ganVzdGlmaWFibGUgZmVhdHVyZSBvZiBhbnkgc2VydmVyLXNpZGUgc2NyaXB0
aW5nCj4gZnJhbWV3b3JrLgo+Cj4KPiAtIGJvb24KPgo+IC0tLSAiV2VibWFzdGVyIFRlY2hjb2Rl
Lk5FVCIgPHdlYm1hc3RlckB0ZWNoY29kZS5uZXQ+Cj4gd3JvdGU6Cj4KPiA+Cj4gPiAtLS0tLSBP
cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPiBGcm9tOiBCb29uIENoZXcKPiA+Cj4gPiBJIHdhbnQg
YSB3YXkgdG8gcXVpY2tseSBkaXNwbGF5IGFsbCB0aGUgaW5mbyBpbiBhCj4gPiB2YXIgLSBhIER1
bXBlciBvdXRwdXQgaWYgeW91IHdpbGwuICBCdXQgbW9yZSB0aGFuCj4gPiB0aGF0LCBsaWtlIGlu
IHNvbWUgb3RoZXIgc2VydmVyLXNpZGUgbGFuZ3VhZ2UsIHlvdQo+ID4gY2FuIHF1ZXJ5IHRoZSBj
b2x1bW4gbGlzdHMgKG9yIGhhc2gga2V5cykgYW5kIGxvb3AKPiA+IHRocm91Z2ggdGhvc2UgYW5k
IHVzZSBhIHBpZWNlIG9mIGdlbmVyaWMgY29kZSB3aGVuCj4gPiBhbGwgeW91IGludGVuZCB0byBk
byBpcyB0byBkaXNwbGF5IGV2ZXJ5dGhpbmcgaW4gdGhlCj4gPiB2YXIuCj4gPgo+ID4gLS0tLS0g
T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4KPiA+IEkgYWdyZWUgLSBzb21ldGhpbmcgbGlrZSBE
YXRhOjpEdW1wZXIgaW4KPiA+IEhUTUw6OlRlbXBsYXRlIGNvbnRleHQgd291bGQgYmUgZ3JlYXQu
Cj4gPgo+ID4gQW5kIHlvdSBjYW4gYWxzbyAieW91IGNhbiBxdWVyeSB0aGUgY29sdW1uIGxpc3Rz
IChvcgo+ID4gaGFzaCBrZXlzKSBhbmQgbG9vcCB0aHJvdWdoIHRob3NlIiBpbiBQZXJsIGp1c3Qg
bGlrZQo+ID4gaW4gYW55IG90aGVyIHNlcnZlci1zaWRlIGxhbmd1YWdlIC4uLgo+ID4KPiA+IGZv
cmVhY2goQGFycmF5KXsKPiA+ICAgICBwcmludCAkXywiXG48YnI+IjsKPiA+IH0KPiA+Cj4gPgo+
ID4KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiA+IFRoZSB0aWdodCBjb3VwbGlu
ZyBvZiBrbm93bGVkZ2UgYmV0d2VlbiB3aGF0J3MgYmVpbmcKPiA+IHNlbnQgZnJvbSB0aGUgcGVy
bCBjb2RlIGFuZCB0aGUgSFRNTCBjYW4gYmUgYXZvaWRlZCwKPiA+IHRoYXQncyB0aGUgd2hvbGUg
cG9pbnQgb2YgdGhlIGRlc2lnbiBvZiB0aGUgdGVtcGxhdGUKPiA+IG1vZHVsZSAodnMgTWFzb24g
d2hlcmUgeW91IG1pbmdsZSBQZXJsIGNvZGUgd2l0aAo+ID4gZGlzcGxheSBjb2RlKSByaWdodD8g
IEl0IGp1c3Qgc2VlbXMgdWdseSB3aGVuIEkgaGF2ZQo+ID4gdG8gdGVsbCBhIGRlc2lnbmVyIHRv
IGdvIGxvb2sgYXQgdGhlIHBlcmwgZmlsZSB0bwo+ID4gc2VlIHdoYXQgaGUgaXMgZ2V0dGluZyBp
biB0aGUgdmFyLiAgSGUgc2hvdWxkIGJlCj4gPiBhYmxlIHRvIGZpbmQgdGhhdCBvdXQgZnJvIG0g
c29tZSBzZW5zaWJsZQo+ID4gY29uc3RydWN0cy4KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug
LS0tLS0KPiA+Cj4gPiBZb3UgbWlzc2VkIHRoZSBwb2ludCAuLi4KPiA+Cj4gPiBJIG1lYW4gLSBk
ZXNpZ25lciBzaG91bGRuJ3QgbmVlZCB0byB0YWtlIGEgbG9vayBhdAo+ID4gUGVybCBjb2RlIHRv
IGZpZ3VyZSBvdXQgd2hhdCB5b3UgYXJlIG91dHB1dGluZyAuLi4KPiA+IEFuZCAic29tZSBzZW5z
aWJsZSBjb25zdHJ1Y3RzIiBhcmUgZG9jdW1lbnRzIHRoYXQKPiA+IGZvbG93IGV2ZXJ5IHByb2pl
Y3QuIEhhdmUgeW91IGV2ZXIgaGVhcmVkIG9mIHRlcm1zCj4gPiBsaWtlIEFQSSBvciBJbnRlcmZh
Y2U/IFlvdSBhbmQgeW91IGRlc2lnbmVyIG5lZWQgdG8KPiA+IGFncmVlIG9uICJJbnRlcmZhY2Ui
IC0gaW4geW91ciBjYXNlIHRoZSBkYXRhIGhlIGNhbgo+ID4gdXNlIGluIHRoZSB0ZW1wbGF0ZSAu
Li4KPiA+Cj4gPiBBbnl3YXkgLSB0aGUgcXVpY2sgYW5kIHNpbXBsZSBzb2x1dGlvbiB0aGF0IGp1
c3QKPiA+IGNyb3NzZWQgbXkgbWluZCA7KQo+ID4KPiA+IE1ha2Ugc29tZXRoaW5nIGEgcnVsZSAt
IGZvciBlYWNoIHRlbXBsYXRlIC0geW91Cj4gPiBjb3VsZCBjcmVhdGUgYSBzcGVjaWFsIHZhcmlh
YmxlLiBTYXkgeW91IGNhbiBuYW1lIGl0Cj4gPiA6ICJ0aGVfZHVtcCIgb3Igd2hhdGV2ZXIuCj4g
PiBBbmQgc2ltcGx5IGR1bXAgdmlhIERhdGE6OkR1bXBlciBhbGwgdmFyaWFibGVzIHRoYXQKPiA+
IHlvdSAocGxhbikgcG9wdWxhdGUgdGhlIHRlbXBsYXRlIHdpdGggLSBvciBzZW5kIHRvCj4gPiB0
ZW1wbGF0ZS4KPiA+Cj4gPiBBY3R1YWx5IC0gdGhpcyBjb3VsZCBiZSBtYWRlIGFzIHBhcnQgb2YK
PiA+IEhUTUwtVGVtcGxhdGUgLi4uCj4gPgo+ID4gQW55d2F5IC0gdGhlbiB5b3VyIGRlc2lnbmVy
IGNvdWxkIGp1c3QgYWRkIDx0bXBsX3Zhcgo+ID4gbmFtZT0idGhlX2R1bXAiPiBhdCB0aGUgZW5k
IG9mIHRoZSB0ZW1wbGF0ZSBpZiBoZSBpcwo+ID4gbm90IHN1cmUgd2hhdCBkYXRhIGhlIGNhbiBh
Y2Nlc3MuCj4gPgo+ID4gT2YgY291cnNlIC0gbmV4dCB0aGluZyBoZSB3aWxsIGNvbXBsYWluIGlz
IHdoeSBpbgo+ID4gdGhlIGhlbGwgaGUgY2FuJ3QgZG8gYSBwcmV2aWV3IGluIERyZWFtd2VhdmVy
IHdpdGgKPiA+IHRlc3QgZGF0YSBhbHJlYWR5IHBvcHVsYXRlZCAuLi4KPiA+Cj4gPiBDaGVlcnMs
Cj4gPiBBbGV4Lgo+ID4gThisSFnetemailissponsoredbwnplunP4ncDoyougo+ID4g3qbYa6Lo
IZaIH4pXrH6K6ShyKYblemsStopDowo+IOWhp22F6d7AAkBex5qtyF6eCKd62Fq2ZqR6yx5qtyGK
eDKi6uWiB+KV6xqx5qzJqyy6t+KeC2F7B5sM5T8s4ANI8tQ0qG22n/9p2yix2dyib9p2J++t+2pZ
aHIn16865opyWJw/e2aW16amVq166x4ocinJmopYp4JYrLR7ZpbXpqZWrXrrHihyKclistssourc
eforP+nethttps//listssourceforgeP+t/lists/listinfj/htmltemplatcocimx6uwKPgo+
Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFlhaG9v
ISBEU0wgliBTb21ldGhpbmcgdG8gd3JpdGUgaG9tZSBhYm91dC4KPiBKdXN0ICQxNi45OS9tby4g
b3IgbGVzcy4KPiBkc2wueWFob28uY29tCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNw
b25zb3JlZCBieTogU3BsdW5rIEluYy4gRG8geW91IGdyZXAgdGhyb3VnaCBsb2cgZmlsZXMKPiBm
b3IgcHJvYmxlbXM/ICBTdG9wISAgRG93bmxvYWQgdGhlIG5ldyBBSkFYIHNlYXJjaCBlbmdpbmUg
dGhhdCBtYWtlcwo+IHNlYXJjaGluZyB5b3VyIGxvZyBmaWxlcyBhcyBlYXN5IGFzIHN1cmZpbmcg
dGhlICB3ZWIuICBET1dOTE9BRCBTUExVTkshCj4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9
NzYzNyZhbGxvY19pZD0xNjg2NSZvcD1jbGljawo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fCj4gSHRtbC10ZW1wbGF0ZS11c2VycyBtYWlsaW5nIGxpc3QK
PiBIdG1sLXRlbXBsYXRlLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlz
dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2h0bWwtdGVtcGxhdGUtdXNlcnMKPgo=

Re: [htmltmpl] Re: HTML::Template bug report: Problems using cache

[Mitar <mm...@gm...>]

Hi!

On 12/1/05, Mathew Robertson <mat...@ne...> wrote:
> That is a bit harsh... And if Sam was to put out a release with bugfixes,
> what would it contain?

I hope it was not. At least it was not meant to be. And I was thinking
about those bugs:

http://rt.cpan.org/NoAuth/Bugs.html?Dist=3DHTML-Template

I think that making an official bugfix release would be nice. And that
it would also show that the module is still alive (as we all know it
is).

And Sam asked me to keep nagging him about that. But it is normal and
understandable if he does not have the time or anything for that.


Mitar

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Boon C. <was...@ya...>]

Well, I guess I should have explained the need of this
with a more solid real world use case.
Recently I am involved in a project using Krang, a CMS
system written in Perl that utilizes HTML::Template. 
Now here is the thing, we are fairly new to the code
base, but in a few days of going through the code and
poking around the code, we were able to implement
quite a few new features for the client.

But our understanding of the system is still immature
and incomplete, and there are times the template var
is being set somewhere in the inheritance chain, and
we know a template can access a specific variable
(through incomplete doc and tmpl_if test), but there
is no way to know how to access the variable without
going through the code tracing out where and what is
sent to the template.  And what if the documentation
misses talking about a var that is sent to the
template?  No one you can find out unless you poke
around the code, but the process can be time consuming
as not all the templates are being set in one file
(due to OO).

I find it surprising that people expect problems can
be solved with documentation, or communication with
the frontend folks.  In the real world, documentation
is never as complete as should, I mean, it's hard
enough to get some to comment their code!  And in the
real world, you don't always start a project with code
that you have written as well.  The need to be able to
introspect and access what is sent to the template
without having the perl code is a useful and
justifiable feature of any server-side scripting
framework.


- boon

--- "Webmaster Techcode.NET" <web...@te...>
wrote:

> 
> ----- Original Message ----- 
> From: Boon Chew 
> 
> I want a way to quickly display all the info in a
> var - a Dumper output if you will.  But more than
> that, like in some other server-side language, you
> can query the column lists (or hash keys) and loop
> through those and use a piece of generic code when
> all you intend to do is to display everything in the
> var.
> 
> ----- Original Message ----- 
> 
> I agree - something like Data::Dumper in
> HTML::Template context would be great.
> 
> And you can also "you can query the column lists (or
> hash keys) and loop through those" in Perl just like
> in any other server-side language ...
> 
> foreach(@array){
>     print $_,"\n<br>";
> }
> 
> 
> 
> ----- Original Message ----- 
> The tight coupling of knowledge between what's being
> sent from the perl code and the HTML can be avoided,
> that's the whole point of the design of the template
> module (vs Mason where you mingle Perl code with
> display code) right?  It just seems ugly when I have
> to tell a designer to go look at the perl file to
> see what he is getting in the var.  He should be
> able to find that out fro m some sensible
> constructs.
> ----- Original Message ----- 
> 
> You missed the point ...
> 
> I mean - designer shouldn't need to take a look at
> Perl code to figure out what you are outputing ...
> And "some sensible constructs" are documents that
> folow every project. Have you ever heared of terms
> like API or Interface? You and you designer need to
> agree on "Interface" - in your case the data he can
> use in the template ...
> 
> Anyway - the quick and simple solution that just
> crossed my mind ;)
> 
> Make something a rule - for each template - you
> could create a special variable. Say you can name it
> : "the_dump" or whatever.
> And simply dump via Data::Dumper all variables that
> you (plan) populate the template with - or send to
> template.
> 
> Actualy - this could be made as part of
> HTML-Template ...
> 
> Anyway - then your designer could just add <tmpl_var
> name="the_dump"> at the end of the template if he is
> not sure what data he can access.
> 
> Of course - next thing he will complain is why in
> the hell he can't do a preview in Dreamweaver with
> test data already populated ...
> 
> Cheers,
> Alex.
> N¬HY޵隊X¬²š'²ŠÞu¼’¦[§?‰ÜŒ¨º
> Þ¦Øk¢è!–ˆŠW¬~Šé®†åzk¶ŠC£
塧m…éÞÀ@^ǚ­È^ž§zØZ¶f¤zËj·!Šx2¢êå¢â•ë±æ¬É«,º·âža{›å?,àHòÔ4¨m¶ŸÿiÛ(±ÙÜ¢oÚv'ï­ûjYhr'ׯ:æŠrXœ?{f–צ¦V­zë®ÉšŠX§‚X¬´{f–צ¦V­zë®Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ–+-²Ê.­ÇŸ¢¸?ë–+-³ùb²Ø§~?á¶imzjej×®±êì



		
__________________________________________ 
Yahoo! DSL – Something to write home about. 
Just $16.99/mo. or less. 
dsl.yahoo.com 

Re: [htmltmpl] Speed

[Octavian R. <ora...@fc...>]

From: "Paul Baker" <pb...@wh...>
>
> > Is the speed of H::T affected if using the following options?
>
> And I'm not sure about die_on_bad_params, but I do believe
> loop_context_vars and global_vars does add a performance hit because
> the engine then has to generate or handle more vars inside a loop than
> if they were turned off.
>
>

Ok, thank you. Do you know if there is another way of using some vars in a
TMPL_LOOP than using global vars?
Can I "localize" them somehow?

I usually need to use some "external" vars which are not keys on the
hashrefs in the arrayref that defines the loops, but because of speed
penalties I don't want to use global_vars => 1.

Are there any tips and tricks on how can I do this without using
global_vars?

Thank you.

Teddy

Re: [htmltmpl] Alternate loops

[Jonathan L. <dat...@gm...>]

Mathew Robertson wrote:
> Hi Jonathan,
>
> I think the exampe of:
>
>  @loop =3D (
>    ...
>    {value_set =3D> 2, count_distribution =3D> 1, sum_of_counts =3D> 36 },
>    ...
>  )
>
> is invalid, since you never generate the loop contruct like that.

"invalid" may be too strong of a word; maybe you mean "unlikely"?

For brevity's sake, I was describing the contents of a variable that's
about to be loaded into the template; I was not intending to address
the question of how it gets put together in the first place.  That
said:

> Usually you would do something like:
>
>   for ($min..$max) {                        # - loop through to max rows
>     push @loop, {                           # \
>       value_set =3D> $_,                      # - make row values
>       count_distribution =3D> make_value($_), # /
>     };
>   }
>   $ht->param(some_loop =3D> \@loop);          # - make rows available
>   $ht->param(sum_of_counts =3D> 36);          # - make max count availabl=
e
>
> The point being that usually you build up loop content dynamicaly, say fr=
om a database
> or a computation, rather than simply outputting static content.

True, but not a point that has much of an impact on my proposal.

Take the example given in the documentation:

  my @words =3D qw(I Am Cool);
  my @numbers =3D qw(1 2 3);
  my @loop_data =3D ();
  while (@words and @numbers) {
    my %row_data;
    $row_data{WORD} =3D shift @words;
    $row_data{NUMBER} =3D shift @numbers;
    push (@loop_data, \%row_data);
  }
  $template->param(THIS_LOOP =3D> \@loop_data);

--

  <TMPL_LOOP NAME=3D"THIS_LOOP">
    Word: <TMPL_VAR NAME=3D"WORD"> <br>
    Number: <TMPL_VAR NAME=3D"NUMBER"> <p>
  </TMPL_LOOP>

Everything after the "my @numbers" line and before the
"$template->param" line is an example of having to jump through hoops
in order to get the information into a "table format" that H::T can
use.  Furthermore, the related template is under some severe
limitations, in that information that has not been put into @loop_data
cannot be displayed from inside a <TMPL_LOOP> tag.

Looking at the same example, but implementing my proposal, you'd have this:

  my @words =3D qw(I Am Cool);
  my @numbers =3D qw(1 2 3);
  $template->param(WORDS =3D> \@words);
  $template->param(NUMBERS =3D> \@numbers);

--

  <TMPL_LOOP>
    Word: <TMPL_VAR NAME=3D"WORDS"> <br>
    Number: <TMPL_VAR NAME=3D"NUMBERS"> <p>
  </TMPL_LOOP>

Much simpler, no?

> Also, I'm not confident that H::T could be extended with the
> list-of-list case (without some re-work), as H::T uses
> recursion for TMPL_LOOPS (eg: when a loop begins, a new
> instance of H::T is created -> it becomes the current context).
> Note that most of my templates use lists-of-lists to produce
> tables, so I do consider this to be a must have.

See, that "current context" bit is something else that I'd like to get
away from with unnamed template loops.  Going back to what you have in
the second quote above: if I use <TMPL_LOOP NAME=3D"some_loop">, I can
only use <TMPL_VAR NAME=3D"value_set"> and <TMPL_VAR
NAME=3D"count_distribution"> within it; I cannot use <TMPL_VAR
NAME=3D"sum_of_counts"> in there, because "sum_of_counts" isn't in the
current context.  Unnamed template loops wouldn't change the current
context, so I'd be able to make use of any or all of the appropriate
arrays or scalars within it.

> The idea of unnamed template loops is a interesting idea, but
> all it really does is to increase the complexity of H::T, for
> no real increase in useability.

I'll have to beg to differ.  As things stand, the script writer has to
have a strong feel for how the data that he provides is going to be
used, and needs to set up the lists of hashes accordingly.  The
template writer is then constrained to display each list-of-hashes in
a separate loop, even if he thinks that the data makes more sense
bundled together in a single loop.  And that's not even mentioning the
"current context" constraint.
With unnamed template loops, the template writer is free to bundle as
much or as little of the available data into a given loop as he feels
is appropriate.  If that's not a real increase in useability, what is?

> PS. In all of my templates, I know of exactly _zero_ cases where I could =
use un-named
> loop variables.

Correction: Every last case you know of _could_ use unnamed loops,
since unnamed loops can do everything that regular loops can.  Not one
of your cases _does_, obviously, since unnamed loops aren't currently
implemented; but that's not the same thing.  And I can think of a
number of cases where unnamed loops would streamline the script
writer's job without complicating the template writer's job.

--
Jonathan "Dataweaver" Lang

Re: [htmltmpl] Speed

[Paul B. <pb...@wh...>]

On Dec 2, 2005, at 12:09 PM, Octavian Rasnita wrote:

> Hi,
>
> I have some questions that I couldn't find an answer for:
>
> Which way of "inserting" vars in HTML::Template is the fastest?
> (or it doesn't make any difference?)
>
> *snip*

Someone can correct me if I'm wrong, but based on the usual perl speed 
generalizations, doing...

   $ht->param(foo => 1);
   $ht->param(bar => 2);
   $ht->param(baz => 3);

...will be slower than doing...

   $ht->param(foo => 1, bar => 2, baz => 3);

...because doing three method calls is more expansive than doing one 
and passing more data. But doing...

   $ht->param({ foo => 1, bar => 2, baz => 3 });

...should be even faster because it is more efficient to pass a single 
hashref in a method call than it is to pass a large list of arguments. 
I have not benchmarked these and have not looked at the under-lying 
code of the param method to be sure, but based on what I know about 
Perl and the speed of method calls and passing arguments, these are my 
assumptions.

> Is the speed of H::T affected if using the following options?

And I'm not sure about die_on_bad_params, but I do believe 
loop_context_vars and global_vars does add a performance hit because 
the engine then has to generate or handle more vars inside a loop than 
if they were turned off.


> Is there a better way of defining the $ht object than defining it for 
> every
> template needs to be parsed?

I don't have an answer for that.

-- 
Paul Baker

"The day Microsoft makes something that doesn't suck is probably the 
day they start making vacuum cleaners."
           -- Ernst Jan Plugge

GPG Key: http://homepage.mac.com/pauljbaker/public.asc

[htmltmpl] Speed

[Octavian R. <ora...@fc...>]

Hi,

I have some questions that I couldn't find an answer for:

Which way of "inserting" vars in HTML::Template is the fastest?
(or it doesn't make any difference?)

$ht->param(var1 => $var1,
var2 => $var2,
var3 => $var3);

or

$ht->param(var1 => $var1);
$ht->param(var2 => $var2);
$ht->param(var3 => $var3);

or another one?

-

Is the speed of H::T affected if using the following options?
(incresed or decreased?)

loop_context_vars => 1,
die_on_bad_params => 0,
global_vars => 1,
-

Is there a better way of defining the $ht object than defining it for every
template needs to be parsed?
For example, defining a general object in a separate package, then using it,
giving it the filename of the template, and possible other options...? Could
the speed be bigger?

I could try to test all these things myself, but if not using them in a real
work environment the results might not be relevant, so that's why I am
asking you.

Thank you very much.

Teddy



Teddy

Re: [htmltmpl] Multiple templates within a template

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

From: cfaust-dougot <cf...@do...>
>I'm getting into the habit of making a single TMPL file (or new single HT object) in which I will have anywhere from 3 to 5 different pages in it, each within its own template if.
>
>From a performance standpoint, how bad is this? 

It sounds to me like you're trading HT's disk (and/or memory caching) for your own memory caching (if you're using mod_perl and keep the HT object instantiated, and let the "if" be processed with each output so it outputs the correct page for the request).

What benefit do you get from having different pages in one template and using an "if" to output the correct one? Why not keep them in seperate templates and load them as needed (using HT's caching)?

Mark

[htmltmpl] Multiple templates within a template

[cfaust-dougot <cf...@do...>]

I couldn't really find the answer I was looking for by search the =
archives, so I thought I would simply ask..
=20
I'm getting into the habit of making a single TMPL file (or new single =
HT object) in which I will have anywhere from 3 to 5 different pages in =
it, each within its own template if.
Quite often there is redundancy within the template if's and I'm =
ultimately only displaying one of the template ifs...=20
=20
From a performance standpoint, how bad is this?=20
Is it costly enough that I really shouldn't be doing it?=20
If it is a problem, is it because it increases the overall size of the =
tmpl file? Or is it because I might be setting multiple =
tmpl_var's,tmpl_loop's etc 2 or 3 times within the template when I only =
needed to do it once?
=20
Everything is under mod_perl and I cache the templates, if that makes =
any difference.
=20
I know I could probably use benchmark to do some tests, but I figured =
I'd try the list first.
=20
TIA
-Chris

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Webmaster Techcode.N. <web...@te...>]

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogQm9vbiBDaGV3IA0KDQpJIHdh
bnQgYSB3YXkgdG8gcXVpY2tseSBkaXNwbGF5IGFsbCB0aGUgaW5mbyBpbiBhIHZhciAtIGEgRHVt
cGVyIG91dHB1dCBpZiB5b3Ugd2lsbC4gIEJ1dCBtb3JlIHRoYW4gdGhhdCwgbGlrZSBpbiBzb21l
IG90aGVyIHNlcnZlci1zaWRlIGxhbmd1YWdlLCB5b3UgY2FuIHF1ZXJ5IHRoZSBjb2x1bW4gbGlz
dHMgKG9yIGhhc2gga2V5cykgYW5kIGxvb3AgdGhyb3VnaCB0aG9zZSBhbmQgdXNlIGEgcGllY2Ug
b2YgZ2VuZXJpYyBjb2RlIHdoZW4gYWxsIHlvdSBpbnRlbmQgdG8gZG8gaXMgdG8gZGlzcGxheSBl
dmVyeXRoaW5nIGluIHRoZSB2YXIuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQoN
CkkgYWdyZWUgLSBzb21ldGhpbmcgbGlrZSBEYXRhOjpEdW1wZXIgaW4gSFRNTDo6VGVtcGxhdGUg
Y29udGV4dCB3b3VsZCBiZSBncmVhdC4NCg0KQW5kIHlvdSBjYW4gYWxzbyAieW91IGNhbiBxdWVy
eSB0aGUgY29sdW1uIGxpc3RzIChvciBoYXNoIGtleXMpIGFuZCBsb29wIHRocm91Z2ggdGhvc2Ui
IGluIFBlcmwganVzdCBsaWtlIGluIGFueSBvdGhlciBzZXJ2ZXItc2lkZSBsYW5ndWFnZSAuLi4N
Cg0KZm9yZWFjaChAYXJyYXkpew0KICAgIHByaW50ICRfLCJcbjxicj4iOw0KfQ0KDQoNCg0KLS0t
LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANClRoZSB0aWdodCBjb3VwbGluZyBvZiBrbm93bGVk
Z2UgYmV0d2VlbiB3aGF0J3MgYmVpbmcgc2VudCBmcm9tIHRoZSBwZXJsIGNvZGUgYW5kIHRoZSBI
VE1MIGNhbiBiZSBhdm9pZGVkLCB0aGF0J3MgdGhlIHdob2xlIHBvaW50IG9mIHRoZSBkZXNpZ24g
b2YgdGhlIHRlbXBsYXRlIG1vZHVsZSAodnMgTWFzb24gd2hlcmUgeW91IG1pbmdsZSBQZXJsIGNv
ZGUgd2l0aCBkaXNwbGF5IGNvZGUpIHJpZ2h0PyAgSXQganVzdCBzZWVtcyB1Z2x5IHdoZW4gSSBo
YXZlIHRvIHRlbGwgYSBkZXNpZ25lciB0byBnbyBsb29rIGF0IHRoZSBwZXJsIGZpbGUgdG8gc2Vl
IHdoYXQgaGUgaXMgZ2V0dGluZyBpbiB0aGUgdmFyLiAgSGUgc2hvdWxkIGJlIGFibGUgdG8gZmlu
ZCB0aGF0IG91dCBmcm8gbSBzb21lIHNlbnNpYmxlIGNvbnN0cnVjdHMuDQotLS0tLSBPcmlnaW5h
bCBNZXNzYWdlIC0tLS0tIA0KDQpZb3UgbWlzc2VkIHRoZSBwb2ludCAuLi4NCg0KSSBtZWFuIC0g
ZGVzaWduZXIgc2hvdWxkbid0IG5lZWQgdG8gdGFrZSBhIGxvb2sgYXQgUGVybCBjb2RlIHRvIGZp
Z3VyZSBvdXQgd2hhdCB5b3UgYXJlIG91dHB1dGluZyAuLi4gQW5kICJzb21lIHNlbnNpYmxlIGNv
bnN0cnVjdHMiIGFyZSBkb2N1bWVudHMgdGhhdCBmb2xvdyBldmVyeSBwcm9qZWN0LiBIYXZlIHlv
dSBldmVyIGhlYXJlZCBvZiB0ZXJtcyBsaWtlIEFQSSBvciBJbnRlcmZhY2U/IFlvdSBhbmQgeW91
IGRlc2lnbmVyIG5lZWQgdG8gYWdyZWUgb24gIkludGVyZmFjZSIgLSBpbiB5b3VyIGNhc2UgdGhl
IGRhdGEgaGUgY2FuIHVzZSBpbiB0aGUgdGVtcGxhdGUgLi4uDQoNCkFueXdheSAtIHRoZSBxdWlj
ayBhbmQgc2ltcGxlIHNvbHV0aW9uIHRoYXQganVzdCBjcm9zc2VkIG15IG1pbmQgOykNCg0KTWFr
ZSBzb21ldGhpbmcgYSBydWxlIC0gZm9yIGVhY2ggdGVtcGxhdGUgLSB5b3UgY291bGQgY3JlYXRl
IGEgc3BlY2lhbCB2YXJpYWJsZS4gU2F5IHlvdSBjYW4gbmFtZSBpdCA6ICJ0aGVfZHVtcCIgb3Ig
d2hhdGV2ZXIuDQpBbmQgc2ltcGx5IGR1bXAgdmlhIERhdGE6OkR1bXBlciBhbGwgdmFyaWFibGVz
IHRoYXQgeW91IChwbGFuKSBwb3B1bGF0ZSB0aGUgdGVtcGxhdGUgd2l0aCAtIG9yIHNlbmQgdG8g
dGVtcGxhdGUuDQoNCkFjdHVhbHkgLSB0aGlzIGNvdWxkIGJlIG1hZGUgYXMgcGFydCBvZiBIVE1M
LVRlbXBsYXRlIC4uLg0KDQpBbnl3YXkgLSB0aGVuIHlvdXIgZGVzaWduZXIgY291bGQganVzdCBh
ZGQgPHRtcGxfdmFyIG5hbWU9InRoZV9kdW1wIj4gYXQgdGhlIGVuZCBvZiB0aGUgdGVtcGxhdGUg
aWYgaGUgaXMgbm90IHN1cmUgd2hhdCBkYXRhIGhlIGNhbiBhY2Nlc3MuDQoNCk9mIGNvdXJzZSAt
IG5leHQgdGhpbmcgaGUgd2lsbCBjb21wbGFpbiBpcyB3aHkgaW4gdGhlIGhlbGwgaGUgY2FuJ3Qg
ZG8gYSBwcmV2aWV3IGluIERyZWFtd2VhdmVyIHdpdGggdGVzdCBkYXRhIGFscmVhZHkgcG9wdWxh
dGVkIC4uLg0KDQpDaGVlcnMsDQpBbGV4Lg0K

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

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

Replied unzipped-content, off-list

Jonathan Lang wrote:

>> PS. I maintain a version of H::T which supports sub-classing so that y=
ou
>>can create your own TMPL tags, see:
>>http://members.optusnet.com.au/~mathew
>>   =20
>>
>
>Nice, except that I can't extract it from the computer that I'm at
>(grumble, WinXP, grumble, public library computer, grumble).  Could
>someone provide Mathew's version, uncompressed, so that I can look it
>over?
>
>--
>Jonathan "Dataweaver" Lang
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users
> =20
>

Re: [htmltmpl] Alternate loops

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

Hi Jonathan,

I think the exampe of:

 @loop =3D (
   ...
   {value_set =3D> 2, count_distribution =3D> 1, sum_of_counts =3D> 36 },=

   ...
 )

is invalid, since you never generate the loop contruct like that.  Usuall=
y you would do something like:

  for ($min..$max) {                        # - loop through to max rows
    push @loop, {                           # \
      value_set =3D> $_,                      # - make row values
      count_distribution =3D> make_value($_), # /
    };
  }
  $ht->param(some_loop =3D> \@loop);          # - make rows available
  $ht->param(sum_of_counts =3D> 36);          # - make max count availabl=
e

The point being that usually you build up loop content dynamicaly, say fr=
om a database or a computation, rather than simply outputting static cont=
ent.

Also, I'm not confident that H::T could be extended with the list-of-list=
 case (without some re-work), as H::T uses recursion for TMPL_LOOPS (eg: =
when a loop begins, a new instance of H::T is created -> it becomes the c=
urrent context).  Note that most of my templates use lists-of-lists to pr=
oduce tables, so I do consider this to be a must have.

The idea of unnamed template loops is a interesting idea, but all it real=
ly does is to increase the complexity of H::T, for no real increase in us=
eability.  That said, there may be a very slight increase in performance =
when output'ing as you are no longer dealing with associative arrays.

Mathew

PS. In all of my templates, I know of exactly _zero_ cases where I could =
use un-named loop variables.


Jonathan Lang wrote:

>Requiring that all loops be handled by iterating through lists of
>hashes leads to a lot of extra work on the script writer's end, and
>results in the template writer having rather inflexible data to work
>with.  I'd like to propose a more flexible alternative, which ought to
>be usable in addition to the current approach:
>
>Allow the script writer to pass ordinary lists to a template.
>
>Allow the template writer to access them using a modified version of
><TMPL_LOOP>:
>
><TMPL_LOOP> <!-- that's right; no loop control variable is given. -->
> <TMPL_VAR list1> <!-- list1 is an ordinary list that got passed to
>the template. -->
> <TMPL_VAR list2> <!-- list2 is another such list. -->
></TMPL_LOOP>
>
>This loop construct would display the first elements of list1 and
>list2 on its first pass, the second elements of each list on its
>second pass, and so on until it exhausts one of the lists (at which
>point it stops).
>
>Without a loop control variable, any variable could be used within the
>loop, not just list-like variables.  So you could do something like:
>
> <ul>
> <TMPL_LOOP>
>  <li><TMPL_VAR value_set>: <TMPL_VAR count_distribution> out of
><TMPL_VAR sum_of_counts></li>
> </TMPL_LOOP>
> </ul>
>
>Given:
> @value_set =3D (2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12);
> @count_distribution =3D (1, 2, 3, 4, 5, 6, 5, 4, 3, 2, 1);
> $sum_of_counts =3D 36;
>
>This would produce:
>
> <ul>
>  <li>2: 1 out of 36</li>
>  <li>3: 2 out of 36</li>
>  <li>4: 3 out of 36</li>
>  <li>5: 4 out of 36</li>
>  <li>6: 5 out of 36</li>
>  <li>7: 6 out of 36</li>
>  <li>8: 5 out of 36</li>
>  <li>9: 4 out of 36</li>
>  <li>10: 3 out of 36</li>
>  <li>11: 2 out of 36</li>
>  <li>12: 1 out of 36</li>
> </ul>
>
>The only restriction would be that ordinary lists can only be used
>within a TMPL_LOOP.
>
>To me, this seems a lot more intuitive (on both ends of the design)
>than the current approach, where the script writer would have to say
>something like:
>
>@loop =3D (
> {value_set =3D> 2, count_distribution =3D> 1, sum_of_counts =3D> 36 },
> {value_set =3D> 3, count_distribution =3D> 2, sum_of_counts =3D> 36 },
> {value_set =3D> 4, count_distribution =3D> 3, sum_of_counts =3D> 36 },
> {value_set =3D> 5, count_distribution =3D> 4, sum_of_counts =3D> 36 },
> {value_set =3D> 6, count_distribution =3D> 5, sum_of_counts =3D> 36 },
> {value_set =3D> 7, count_distribution =3D> 6, sum_of_counts =3D> 36 },
> {value_set =3D> 8, count_distribution =3D> 5, sum_of_counts =3D> 36 },
> {value_set =3D> 9, count_distribution =3D> 4, sum_of_counts =3D> 36 },
> {value_set =3D> 10, count_distribution =3D> 3, sum_of_counts =3D> 36 },=

> {value_set =3D> 11, count_distribution =3D> 2, sum_of_counts =3D> 36 },=

> {value_set =3D> 12, count_distribution =3D> 1, sum_of_counts =3D> 36 },=

>)
>
>Bulky and painful.
>
>-
>
>You might even have it handle lists of lists, by nesting TMPL_LOOPs:
>
> <table>
> <TMPL_LOOP>
>  <tr><TMPL_LOOP><td><TMPL_VAR count></td></TMPL_LOOP></tr>
> </TMPL_LOOP>
> </table>
>
>and
>
> @count =3D ([2, 3, 4, 5, 6, 7],
>           [3, 4, 5, 6, 7, 8],
>           [4, 5, 6, 7, 8, 9],
>           [5, 6, 7, 8, 9, 10],
>           [6, 7, 8, 9, 10, 11],
>           [7, 8, 9, 10, 11, 12]);
>
>produces:
>
> <table>
>  <tr><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td></tr>
>  <tr><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td></tr>
>  <tr><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td><td>9</td></tr>
>  <tr><td>5</td><td>6</td><td>7</td><td>8</td><td>9</td><td>10</td></tr>=

>  <tr><td>6</td><td>7</td><td>8</td><td>9</td><td>10</td><td>11</td></tr=
>
>  <tr><td>7</td><td>8</td><td>9</td><td>10</td><td>11</td><td>12</td></t=
r>
> </table>
>
>lists of lists of lists would also be possible, but the usefulness of
>lists of lists is already getting close to marginal.
>
>-
>
>I have an idea that would allow script writers to load hashes into a
>template as well; but IMHO that's not nearly as useful as loading
>ordinary list variables.
>
>--
>Jonathan "Dataweaver" Lang
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log f=
iles
>for problems?  Stop!  Download the new AJAX search engine that makes
>searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
>http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
>_______________________________________________
>Html-template-users mailing list
>Htm...@li...
>https://lists.sourceforge.net/lists/listinfo/html-template-users
> =20
>

Re: [htmltmpl] loop through a hash structure without knowing the hash keys?

[Jonathan L. <dat...@gm...>]

Boon Chew wrote:
>  It might be difficult to do for multilevel nested data structure, but I
> think having support for one of the most common data structure, array of
> hash, is a good start, because array of hash mirrors the structure of a
> resultset coming back from a DB query.

You're reading my mind.

First off, multilevel nested data structures are quite doable.  I just
posted an idea for getting H::T to handle normal lists, lists of
lists, lists of lists of lists, etc.  As I mentioned, I also have some
ideas for handling hashes, at which point you can handle lists of
hashes, hashes of lists, hashes of hashes of lists of lists of hashes,
or whatever other insane combination you might choose.  Admittedly, I
see few uses for anything beyond ordinary lists, lists of lists, and
lists of hashes; but that's (literally) another topic.

But lists of hashes do hold a special status, due to their similarity
to database tables: I wouldn't be averse to an extension to H::T that
lets you use SQL SELECT queries as substitutes for loop control
variables, letting the template writer merge tables, sort their
contents to his liking, filter out unwanted records, or create new,
calculated fields from existing ones.  There is value to the notion of
viewing lists of hashes as tables.

>  Currently we can use tmpl_loop to loop through the array elements (or
> thinking in terms of DB, the rows), so that's taken care of.  What's miss=
ing
> is a way to get the hash keys, so maybe there can be a contextual var tha=
t
> gives you the hash keys (from the DB perspective, the columns or fields),=
 as
> in __ColumnList__ or something that you can loop through with.  Sorry I a=
m
> just thinking out loud here, as I don't know enough about HTML::Template
> internals enough to know that's possible or makes sense.

This capability seems a bit excessive to me; the template designer
should rarely (if ever) have to write a template that needs to find
out for itself about the structure of the data that's being provided
to it.  When dealing with DB applications, it's rare that the
application needs to look up the column names; usually, it is told by
the programmer what column names to expect and works with that.

And with H::T, if the template in question really needs to know the
names of the keys of a particular hash, the script writer can
explicitly load them into the template.  Part of the H::T design
philosophy is that the template does little more than to look up
pre-processed data and to decide how to dress it up; even the SQL
SELECT suggestion that I made above puts more work into the hands of
the template writer than the basic design philosophy would recommend
(heck, doing simple comparison tests such as "name > 5" is verboten in
the standard form of the application).

--
Jonathan "Dataweaver" Lang