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

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 => 1 that shows all the params passed
>to the template in a Dumper fashion will be quite
>useful.
>
>
>- boon
>
>--- Carl Franks <[email protected]> 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 <[email protected]> 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"
>>>      
>>>
>><[email protected]>
>>    
>>
>>>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Þµés(S(X¬²s('²S(Þu¼'¦[§?0/00ÜOE¨º
>>>>Þ¦Øk¢è!-^S(W¬~S(é(r)+åzk¶S(C£
>>>>        
>>>>
>塧m...éÞÀ@^Çs(­È^z(§zØZ¶f¤zËj·!S(x2¢êå¢â.ë±æ¬É«,º·âz(a{>å?,àHòÔ4¨m¶Y"ÿiÛ(±ÙÜ¢oÚv'ï­ûjYhr'ׯ:æS(rXoe?{f-צ¦V­zë(r)És(S(X§,X¬´{f-צ¦V­zë(r)Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ-+-²Ê.­ÇY"¢¸?ë?-+-³ù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
>
>
>-------------------------------------------------------
>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
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/html-template-users
>  
>