I agree too - what I was trying to say was that, I dont think it is even technically possible to do it generically.

Can you think of an example of how to do it generically?  If you can, I could quite easily modify my H::T version to support this functionality.


Boon Chew wrote:

I agree with you that the coupling cannot be totally avoided, but being able to deal with template var generically in the presentation layer is very useful in avoiding having to create duplicate html code that are doing exactly the same thing. 

- boon

Mathew Robertson <mathew.robertson@netratings.com.au> wrote:
The coupling of a template to the template-params is something that cant really be avoided - at some point the template designer has to have some understanding of what template-variables are being generated.  Since you are the developer creating the code that generates the template-variables, it is your responsibility to "publish" the variable names and their meaning, it is not up to the template designer to "figure out" what they are and what they represent.

That said, there is a justified argument for wanting something like a <TMPL_DUMP some_var> which writes a dumped-block into the target page.


PS. I maintain a version of H::T which supports sub-classing so that you can create your own TMPL tags, see: http://members.optusnet.com.au/~mathew

Boon Chew wrote:
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.

Imagine yourself wanting to output all the info in a reference to an array of hashes (which essentially mimics a database table), the HTML code can really be made the same if a construct is available to loop through things.

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 from some sensible constructs.

- boon

Mathew Robertson <mathew.robertson@netratings.com.au> wrote:
It sounds like you need a tool which simply dumps the template variable names (ie: using the $ht->params() function), rather than some special mode to H::T


Boon Chew wrote:
Ya sorry, that's what I meant.

Right now I am working on some site code, and the designer sometimes have to come to me for stuff because he doesn't always know what hash keys I am passing to him (say sometimes I might add a new one, sometimes he mistype one, etc.).  The whole point of doing this template separation is to decouple things, but if the designer can only figure out what's being passed into the template by looking at the module code, it kinda defeats the whole purpose.

It would be such great convenience to be able to dump the whole thing on the HTML with a call like this:

<tmpl_var story_loop>


<tmpl_loop story_loop>
  <column_var>   <-- outputs all keys here

Carl Franks <fireartist@gmail.com> wrote:
> e.g.

a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs
that would be

my @loop = (
{name => 'a'},
{name => 'b'},

$tmpl->param( students => \@loop );

If you knew that already, give an example of what sort of data you
want to put in, and what you want the HTML to look like.


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!
Html-template-users mailing list

Yahoo! Personals
Single? There's someone we'd like you to meet.
Lots of someones, actually. Yahoo! Personals

Yahoo! DSL Something to write home about. Just $16.99/mo. or less

Yahoo! DSL Something to write home about. Just $16.99/mo. or less