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 _______________________________________________ Html-template-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/html-template-users
