in reply to Meditations On HTML In Perl
I think the trick is using a templating system that allows you to use perl in it. This way, you can embed presentation logic in the presentation docs (templates) and keep the application logic clean.
In a typical web app you can manage the information flux like this:
--------- ------- --------- ------- ----------
| REQUEST | --> | DISP. | --> | APPLIC. | --> | PRES. | --> | RESPONSE |
--------- ------- | LOGIC | | LOGIC | ----------
--------- -------
^ ^
| |
v v
------- ----------
| CLASS |- | TEMPLATE |-
------- |- ---------- |-
------- | ----------- |
------- -----------
Note: DISP is for dispatcherFor templates, I am opting more and more for a mixed system, including ePerl for power and simple substitution/fixed chunks for speed when power is not needed.
In a sample case, the application subsystem can generate an object of class PersonList and the presentation subsystem passes it to a template supposed to show name and age of every person in the list. The template contains something along the lines of
where template personRow is a simple substitution template of the form<: # get parameter personList # this is the only way the template gets # information from other layers my $pList = param('personList'); :> ... <table> <tr><td><b>Name</b></td><td><b>Age</b></td></tr> <: for my $person ($pList->getAsList()) { print template('personRow')->apply( name=>$person->name, age=>$person->age ); } :> </table>
<tr><td><:name:></td><td><:age:></td></tr>
The presentation subsystem can make use of modules and ad-hoc subroutines for automatic generation of HTML, which should not be accessed by the application subsystem.
One advantage of this approach is that even if things can get messy with the mixture of Perl and HTML, when something breaks it's easy to find where the error is located.
|
|---|