Select lists are simple to populate using HTML::FillInForm. Templates get cluttered up very quickly if you try to fill in forms using template tags. They also become much harder to validate (eg " />). Also, if you allow the code to generate the form fields, then you remove the ability of the template designer to change the form fields.

You may argue that HTML::FillInForm needs to have some HTML code in it in order to be able to fill in the HTML form. But it is effectively doing the same thing as a template parser, searching through the HTML for tags that it recognizes (ie HTML form fields), and altering them by assigning a value to the form field. It in no way limits what the template designer can do with the template (ie a select list could be replaced with a series of radio buttons without requiring any code changes, and without needing to alter or adjust any template tags for that matter).

Of course HTML::FillInForm doesn't actually generate the form fields for you, but that is really the job of the Template anyway. In my templates I always try to statically define my form fields unless an option list is dynamically generated by the code. Then a simple loop will do (remember, there will always be some logic in your templates, but it should be display logic only).

Separating code and HTML is easy. You just need to find the right toolset that works for you...

- Cees

you're just not trying hard enough :)

this is how i do it.

I think it is never trully possible to seperate design and logic

IMHO, you should take care to differentiate applicative-logic and GUI-logic, and consider 3 abstraction layers:

1. HTML-Template data, aka GUI elements, look-and-feel, skins, whatever you call it.
2. GUI-logic, tiny code elements, totally dedicated to data appearance. There you'll use HTML::Template modules or equivalent to handle HTML data from above layer. Taking an OO-approach, you may define here a "widgets" hierarchy of specialized objects.
3. Lastly, You'll have applicative-logic dedicated to manage applicative-datas and providing them to users through the help of above layer functionnalities.

                   +-------+
                   | Users |
                   +-------+
                       ^
                       |
                       v
+------------+   +-----------+
| HTML-Datas |-->| GUI-logic |
+------------+   +-----------+
                       ^
                       |
                       v
             +-------------------+
             | Applicative-logic |
             +-------------------+
                       ^
                       |
                       v
                   +-------+
                   | Datas |
                   +-------+

Pro: Design and logic are separated.

Cons: You'll have to stricly follow the rules of responsability separation when developping the differents layers. Anyway, you'll have a bit more code to produce and support all caveats involvde (more code => more bugs => more tests required => less time).

This kind of slicing gives you the basements to build applications decribed as 'Model-View-Controller' in Design-Pattern litteracy.

Updated:corrected some typos and added schematic.

Hi MUHA,

Same sentiment here. Basically, the options are as follows:

1) no attempt at separation - the perl script contains both code and html

2) some attempt at separation - part of the logic is moved to the template

3) strict separation - no html in code

(3) gives you clean and highly maintainable code but is hard to achieve in some cases. I've been through (1) and the result is ugly and difficult-to-maintain code (which has lots of html in it). (2) seems like a neat solution :)

The point is not to keep ALL logic out of your template but to keep everything except display logic out. Your "another way" approach does not put any application logic (database work, user pref manipulation, etc.) in the template. Having to update both the Perl code and the templates when adding a new thing to be displayed is not a bad thing. There are always these two tasks (update code, update display) even if you have no separate templates.

By the way, I would make each nodelet a separate included template, and just pass a list of nodelet templates to include.

You could also drive your "nodelet_title" / "nodelet_contents" method within a Nodelet class, which, when subclassed, fills nodelet_contents from its own private template file.

So you end up with a top-level display module, and each of the "objects" contained within are able to generate their own contents, possibly through their own templates. I am currently using this, am able to keep the logic and display seperate, and have not run into too many problems.

Most of y problems come down to data structures, and shifting between structures for the program and structures for the display (H::T) has been reduced to a couple of translation routines.

--MidLifeXis

I have worked extensively with templating systems (mostly in Java Model 2 webapps, I fear) and I believe that what actually matters is separating data production from display logic. This usually means that on one side you decide WHAT has to be shown to the user and on the other side you decide HOW. This does not automagically imply that all logic has to be on the first side; and this is a serious flaw of pure-templating systems. As the templating logic might be weak, you end up doing elaborations in the WHAT part just to fill in HTML controls. This is the wrong way to do it.

My best experiences have been with Model 2's where:

• All appication flow logic is centrally managed (might be a servlet, or an invonking stub cgi, or what), together with security and sessions and error control.
• Data elaboration (the WHAT) is modularly loaded by the central manager, so you can plug and play new logic in the system
• Data presentation logic (the HOW) is altogether independent but heavily programmable; might be a different CGI, or a JSP/ASP page or a Perl module called after the proper elaboration took place; anything that might load an external library for common layout units
• HTML controls are not embedded in the template as pure text but as function calls. This way is easy to accomodate all the quirks of HTML like SELECTs, radio buttons, disabled fields, hidden fields and all the other pure HTML nuisances. You can also build "custom" controls, like e.g. a Date control made of three combos (day, month, year) that you want to use logically as a single unit.

Hope this helps (though not too much Perl-specific...)

MUBA,
You raise a valid point, what concerns me the most with code I write and/or maintain is when architecture says that code and display logic are supposed to be seperate but you end up resorting to stuff like.

my $t= HTML::Template->new( $sometemplate );
my $insert = $q->table ( $self->build_some_table );
$t->param ( bigtable=>$insert );

This is obviously a naff example, since $insert should be a TMPL_INCLUDE (if you talk HTML:Template).

As raised earlier , display logic within templates is seen to be a necessary evil, less important that seperating WHAT data should be rendered as opposed to HOW that data should be presented. Your code should build valid structures of data that make sense to your templating system.

What this suggests to me is that there is room in the design for a pre-output process between generating valid data and filling a template with that data. When I find myself writing objects with a data struct one way, but a method to output something that makes sense to a template system. eg

my $self = Some::CGI::Class->new( %params );
$self->update_data;
return $self->template_data;

It feels like the reformatting of my object's data for a template system is NOT the responsibility of my object. There ought to be a preprocessing phase. Yet another level of complexity. This pre-processing stage is where I would expect the addition of things like odd/even line BG color changes, or turning a structure inside out to list it as entities by sorted key. For example , your method returns an hash of object references with names as keys that are valid and relevant to the current application's run_mode, you pass that data structure to a template preprocessor because you would like the data ordered by keys and flattened into an array of hashes suitable for a TMPL_LOOP. MIght look more like.

$self->update_data;
my $t = HTML::Template->new( $sometemplate );
my $tpp = HTML::Template::PreProcessor->( hash=>'sorted' , style=>'array' , object=>$self );
$t->param ( $tpp->preprocess );
return $t->output;