Actually that should say "one of the problems..."
Most templating systems out there work in one of two ways:
1. a bi-directional manner, where you have both systems calling into the
template, and the template calling out to code. Take for example TT, you
can have a module call the template toolkit to generate a page, and the
page can execute functions elsewhere, calling back into Perl-space.
2. A uni-directional manner, but in (IMO) a backwards direction, where the
template calls into Perl-space. Systems such as ASP are like this.
What AxKit allows you to do (you are not prevented from using the above,
but its a bad idea, I think), is have a uni-directional system where the
template _never_ calls backwards in the procesing stream - it is always
forward looking. The advantage of this is that you can build systems where
there's never any *incentive* to build some small component that you might
embed some HTML tags to add an extra feature (in Perl-space) because you
should never have to output tags in your coding stage.
To picture this better I imagine it as a forward moving pipeline, from
initial "resource" (the XML file, or whatever the URL maps to), to
delivering the file:
Res ---> Process ---> Process ---> Process ---> Delivery
Now I picture the bi-directional systems:
Res ---> Process ---> Process ---> Process ---> Delivery
\ / / /
\ / / /
[ P E R L -- S P A C E -- P E R L -- S P A C E ]
Thats not actually *such* a bad idea, because at least you're requesting
the resource, not the process.
Now picture the other uni-directional systems:
Process ---> Process ---> Process ---> Delivery
\ \ \
\ \ \
[ P E R L -- S P A C E -- P E R L -- S P A C E ]
There is no resource. What your browser requests is not a resource but a
stylesheet!
[Its worth noting that I've shown several processing stages here, but in
reality not many templating systems support more than one processing
stage]
Thats why I prefer AxKit's method, which is the first diagram. I just find
that neater. I also realise that this may irk some people, because my
concept of Perl-Space here is a virtual one - there's no real separate
perl space in most of these systems, its just a conceptual separation. But
to a designer working on a web site I think the forward pipeline
processing makes more sense. I'm certainly not suggesting any increase in
speed from the forward processing methodology.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
