Re^2: Code and html separation - always or mostly doable?

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 %]
[download]

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 %]
[download]

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.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^2: Code and html separation - always or mostly doable? Select or Download Code

Replies are listed 'Best First'.
Re^3: Code and html separation - always or mostly doable? by amw1 (Friar) on Jun 16, 2004 at 14:33 UTC
Another feature of TT that works well with blocks is the macro stuff. It allows you to write "functions" to do various things. i.e. this takes a scalar and a list or scalar. If the scalar matches the other scalar or matches a value in the list the macro resolves to "selected" otherwise it does nothing. (used to find selected values in a <select> list. [% # sets selected if both values match # tries to see if either side is an array to try and find a match # out of an array of possibly selected values. This will work for m +ultiple # select lists. %] [%- MACRO is_selected(val1, val2) BLOCK -%] [% IF val1 == val2 %] selected [%- selected = 1 %] [% END %] [% IF !selected %] [%- FOREACH value = val1 -%] [%- IF value == val2 -%] selected [%- selected = 1 -%] [%- LAST -%] [%- END -%] [%- END -%] [% END %] [%- IF !selected -%] [%- FOREACH value = val2 -%] [%- IF value == val1 -%] selected [%- LAST -%] [%- END -%] [%- END -%] [%- END -%] [%- END -%] [download] This lets you do things like. . . . `[% # selected items is a list of what should be selected # from this list %] <select name=foo> [% FOREACH select_item = option_list.keys %] <option value="[% option_list.$select_item.value %]" [% is_select +ed(option_list.$select_item.value, selected_items %]> [% option_list.$select_item.display_name %] </option> [% END %] </select>` [download] I have not seen anything in HTML::Template that will let me come close to being able to do this. Most of the work that the template is doing would have to be shifted into the perl code. with html::Template (afaik, I stopped using after I got approval to use TT). In the above example option_list is a hash (that for sake of argument I got from a library call that I don't control). In H::T I'd have to re-write that structure into an array, I'd also have to resolve the selected attribute inside the perl code. The only place where those things are needed are for the display, so why should they be in the perl code. Granted, there is logic in the templates now, but it is solely DISPLAY logic. It is not processing logic. The split I try to get is to not have ANY display logic in the perl code and to not have ANY processing logic in the template. Stuff like properly formatting a date gets put into the template. Stuff like cooking data before it is put into the database lives in the perl code. There seems to be a fairly large camp that does not want to put any logic inside the templates. They are right too. :) Sorry if this is a bit long winded but I really enjoy working with this stuff.	[reply] [d/l] [select]
Re^4: Code and html separation - always or mostly doable? by geektron (Curate) on Jun 16, 2004 at 17:49 UTC
there's an even easier way to do that one ... `[% mycgi.popup_menu( '-name' => 'mylist', '-values' => [ 1,2,3 ], '-de +fault' => 2 ) %]` [download] i used that all the time when i was using TT. let the CGI.pm plug-in do its job.	[reply] [d/l]
Re^3: Code and html separation - always or mostly doable? by elwarren (Priest) on Jun 17, 2004 at 19:14 UTC
I've started working in this mode as well since switching to CGI::Application, using templates for layout and CGI for form generation. Can you share some MVC style perl here?	[reply]


Don't ask to ask, just ask
	PerlMonks