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...)
