[mod_python] XSLT versus 'traditional' templating (was: mod_python Live examples)

Nic Ferrier wrote:
> Your architecture sounds more complicated than the one I use. I have
> business methods that deliver XML. The XML gets transformed into HTML
> (or not) by particular mod_python handlers. It's a very code based
> approach. 

(And yet, still under 300 lines of Python!)

There are two reasons I chose the approach I have.  First, I am still 
dealing with the top layer of the application: views and actions.  The 
business methods may or may not be implemented using XML, but when a 
page is being viewed, the data retrieved for that page will be expressed 
as XML.  Thus, I insert the view level objects that know how to get 
business results expressed in XML.  I have multiple modules allowed per 
page to allow reuse: a menu module or a reminders module will commonly 
be reused, and I'd rather just say "This view will use the reminders 
module" and let the XSLT worry about how and where to put the output of 
that module in the final display.

> In my architecture, there is no aggregation of XML from collections of
> business methods (though there could be if it was pragmatic). There is
> no special 'view' definition. There is no need for a pluggable
> translation layer. The mod_python parts of the architecture are *very*
> disposable.

The pluggable translation layer would allow for me to replace XSLT with 
a system that parsed the XML as template variables for processing in 
some other template system.  Which I will probably never use.

As I'm still dealing entirely at the top, /mod_/python could perhaps be 
replaced with a CGI python, but the point is to map between a user's URI 
request and business code that's got no reason to know or care how it's 
being accessed.

> And note that XSLT doesn't have to be slow; there's quite a lot of
> research going into improving speed. The pipelining approach has
> already been taken:
>   http://xml.apache.org/xalan-j/xsltc_usage.html

Sorry, but I'm not sure what you mean by pipelining.  Since an XSLT 
document can, at any point, examine any part of the source document, you 
/must/ have the entire source document available to perform a transform. 
  Consider how you would implement <xsl:value-of 
select="//foo/bar[@baz='quux']"> without a full document, for instance. 
  In essense, XSLT is a document transformation tool, whereas 
traditional HTML templating mechanisms, including PSP, are stream 
templating tools.

On the other hand, it's perfectly valid to compile the XSLT document to 
some other, more convenient form, thus saving on the parsing, and it's 
also valid to cache DOM trees instead of XML strings.  But these don't 
change the basic fact that an XSLT transformation is still more complex 
than your ordinary run-of-the-mill template translations.

> In a RESTfull application you could also just add another server.

And I am talking not about scalability performance, but about 
per-request response time.  If the system starts too slow to use for one 
user making one request at a time, scaling well will simply mean it can 
be too slow for lots of users at once.

> Hmmm... but unless you translate the whole page you don't know that
> there won't be an error that you should signal with 500 (or
> whatever). 
> This is true for all templating applications, those that return data
> before translation completion are inherently weak.

Yes, this is true.  You can work optimistically, though, and say that in 
a well tested production system, pages will not have parsing/templating 
errors.  Or, you can say that they will only very rarely have them, and 
in your approach prefer the case where those such errors do not occur. 
In streaming templates, you can simply put data out to the client 
browser as fast as you get it, and if a parsing error occurs, you will 
fail ungracefully - but hey, it's an ungraceful and (hopefully) unlikely 
error.  When you're transforming a document, you cannot perform the 
transform until you have an entire document available to transform, and 
thus you cannot send data to the client until near the end of your 
processing.

Same overall response time, but a far slower perception.

> Python doesn't have 'standard' XSLT support yet... but when it does it
> will be possible to pass DOMs around instead of XML character
> streams. That will speed things up considerably.

Sure, or you just say that you expect DOMs to be of the type you can 
handle.  You're defining an API, you can also define the types of the 
arguments and return values.

> And even though there is no 'standard' XSLT support I still think
> mod_python is a *very* good tool for RESTfull applications like this.

Yes, I'm not denying that.  My main claim here is that XSLT approaches, 
and any approach that outputs (correct) XHTML, will always /feel/ slower 
to the user than streaming template approaches, because in the first 
case the entire document must be available to transform against, and in 
the second case the entire document must be parsed before rendering begins.

These aren't reasons to avoid the technologies, they are tradeoffs. 
Your application will almost certainly feel slower, but it's likely to 
have much better decoupling and maintainability, if you use XSLT to 
transform XML data to markup.

-- 
bje