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

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 missing
> is a way to get the hash keys, so maybe there can be a contextual var that
> 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 am
> 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


-------------------------------------------------------
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_idv37&alloc_id865&op=click