> According to Rasmus Lerdorf:
>
> > > > Those introduce more complex problems.
> > >
> > > And they are, of course, inevitable with almost any templating
> > > system.
> >
> > You know, PHP was once just a templating system.
> [...]
> > Then I figured it would be a good idea to add stuff like
> > IF/LOOPS/etc so I could manipulate my tags a little bit.
> >
> > Now, 5 years later, people are writing template systems that sit on top of
> > PHP because they are writing business logic in PHP which means yet another
> > template system is needed to separate code from layout.
> >
> > I wonder how many layers of templates we will have 5 years from now.
>
> I think a lot of unnecessary complexity comes from the fact that
> most of the template systems (and apache modules in general) want
> to output the html as a side effect instead of accumulating the
> page in a buffer or just returning a string containg the html plus
> a status value to the caller. This means that you can't easily
> make nested sub-pages without knowing ahead of time how they
> will be used, and worse, if you get an error in step 3 of generating
> a page you can't undo the fact that steps 1 and 2 are probably already
> on the user's screen. If the template language offers some
> flow control and logic and the ability for one 'page' to return
> a status plus a string containing it's html to another page that
> includes it then you wouldn't need a different template system
> to separate logic from layout, you would just put them in different
> pages, letting the 'code' page include the layout elements it wants.
The IO Layering in Apache2 would be a good place to do this. It really
shouldn't be a module's job to buffer its output. A module should do its
thing and feed its output back to the web server. The web server should
then determine if any other modules need to massage the data or whether it
is time to feed it to the socket.
-Rasmus
