On Thu, 2008-04-10 at 08:59 -0400, Robert Koberg wrote:
On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
One usecase (which is actually something I need to do in the next release cycle of my software): the output of the Lisp side (xml) gets transformed by Apache output filters (xslt transformation). All "visual" design on my customer's website is done by XSLT stylesheets, so design changes (usually once a year :) can be done by just rewriting the stylesheets - the content (in XML) is never touched (as a nice side effect the content can be viewed in different styles). The small Lisp based part of the website currently has to use (x)html and every design change needs to be hardcoded in all TAL templates ...
mod_xslt2 seems pretty limited. From:
In case you responded to my message: did I ever mention mod-xslt2? We use our own xslt transforming module using Daniel's excellent libxslt (unfortunately the module is named mod_xslt, but it's actually much older than the well known modules :) When I hacked the first version it was meant as a joke to make fun of the java software used back then. I can't really comment on mod-xslt2 since I only use it on a rather seldom exposed area of the website but I don't think it's especially slow. My only critique would be that it suffers from a severe "second implementation syndrome" - there _seems_ to be quite a lot of premature (?) optimization and feeping keaturism IMHO. Our little module doesn't even bother to cache the compiled stylesheet - every request reads, parses and compiles the needed stylesheets (and boy do they overuse includes and imports :-) and the transforms the content. So far we seldom had performance problems, even so the site runs on stock server hardware.
5.1.9 Increasing performance
<snip/>
Since mod-xslt2 is part of apache itself, a pipe is impossible to use, unless we fork apache one more time, slowing things down.
The simplest approach has thus been used: creating a temporary file, let other modules write the replies in there, and then parse the temporary file. However, by using temporary files, we hit I/O performance issues.
<snip/>
Where's my babelfish?
plus, it is only XSL 1.0. There was someone working on an XSL processor in lisp, but I don't think it is ready yet (forgot the name).
Yeah. Only XSLT 1. IMHO that's a feature, not a bug. XSLT 1 had a very clear operational model (by accident, i fear, they seem to have inherited it from the DSSSL past) that should be near and dear to us Schemers^H^H Lispers - purely functional without assignment.
Java is currently the best environment if you have to deal with XSL transformations server side. If you are using XSL 1.0 only, you could just do the transformation on the client -- pretty much all browser now support XSL 1.0.
Last time we tested that wasn't a convincing option since that required the transfer of stylesheets (since the site uses a rather modular stylesheet setup that resulted in a noticeable increase in server load).
Cheers, RalfD
best, -Rob
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel