On Sep 13, 2006, at 9:28 AM, Frank Wiles wrote:
What I typically recommend to people is that they use a template
engine like Template-Toolkit.org. You simply pass it a Perl data
structure and then you have all of the same transformation
possibilities as XSLT ( at least as I understand it ). And if you
ever need the data as XML, you simply create a template for
that ( or pass a special option to your handlers to return XML,
etc. ).
I agree with everything said so far
Perl Data Structures
Templating Engines
only toss into XML if you really want to. otherwise why bother with
2x the work?
I go a step further...
All of my packages return Perl data structures
The structures are then tossed into an *abstract* template class
That abstract class wraps several templating engines , and will
output to any of them on the fly. This way i can use Petal and
HTML:: templates with the same app. I just pass a different render
flag or set a variable/constant.
If you did that, you could just wrap something that will parse the
perl structure into XML (or write a template to do it in your
langauge of choice )
If you're wondering why I'm wrapping in an abstract class, here's the
top 5 reasons
It makes me less 'locked into' a templating engine
I can trivially switch engines on some pages where there are
performance concerns ( Petal was killing me on a specific page
render... but HTML::Template redid it in a fraction of time )
It's less code to change when I need to switch templating engines
It's less code to change when I want to switch templating engines
I've already switched templating engines before, it wasn't fun.
All of the 'web frameworks' do it to offer users better choice. I do
it to keep my options open.
