Template::Toolkit is a great system.
One of the problems I find when making pages with lots of interactivity is that you want to make "subroutines" that create parts of the HTML.
Example: in a CMS that I'm making - yes, another one - I have a page that lists the document tree, with "nieuw" links that open the editor for a new page. These links can be put on several parts of the page. To simplify this, i made a BLOCK, like so:
[% BLOCK new_page %]
<td width=10><a href="[% editbase %]?action=open&type=page&parent=[% p
+age.id %]"><img src="[% imgurl %]/filenew.gif" alt="N"></a></td><td c
+olspan="[% span %]" align="left"><a href="[% editbase %]?action=open&
+type=page&parent=[% page.id %]" class="new">Nieuw</a></td>
[% END %]
Here, the page items are Class::DBI objects.
Now, whenever I want to to show these links, I do:
[% IF form.action == 'new' %]
[% INCLUDE new_page page=some_page span=2 %]
[% END %]
TT uses the same syntax to include other templates, so if needed, I can move the BLOCK to a seperate file without having to change the calling code.
By the way, I use a seperate hash-ref "form" to store the values I want to set in the form on the editor.
This $form hashref is initially filled with the values from the CGI request, but it allows me to change the values in "form" (for instance, with data from the $page object from the database) but still have the original request object lying around if I need it.
This is a nice seperation of concerns that is very much used in the Struts java MVC framework, and works pretty well for more complicated interactions.
|