But at the same time, this use of TT just seems custom made for my application, with th epossible exception of this last outrageous desire. I mean, imagine, you've got data that looks like
year x 5
- class x 3
--- sub-class x 5
----- data rows x 50
This just screams for
and then$data{$year}{$class}{$sub-class}{row-element-i} = 'foo';
and, bing!, you're done, with the data generation completely dissociated from the layout generation.<table> [% FOREACH year IN data.keys.sort %] <tr><td colspan=x>Year [% year %]</td></tr> [% FOREACH class IN data.$year.keys.sort %] <tr><td>spacer</td><td colspan=x-1>Class [% class %]</td></tr> [% FOREACH sub-class IN data.$year.$class.keys.sort %] <tr><td colspan=2>spacer</td><td colspan=x-2>Sub-Class [% sub +-class %]</td></tr> <tr> [% FOREACH element IN data.$year.$class.$sub-class.keys.sort +%] <td>[% data.$year.$class.$sub-class.$element %]</td> [%END%] </tr> [%END%] [%END%] [%END%] </table>
This is the kind of power that made me fall in love with TT.
My alternative - or at least the only one of which I'm aware, would be to do all that html generation inside the Perl script and export $data_table_html_string to the template.
In reply to Re^2: Reverse sort order in FOREACH in Template Toolkit
by punch_card_don
in thread Reverse sort order in FOREACH in Template Toolkit
by punch_card_don
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |