[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: performant templating language for XML
I spent some time looking for just such a beast, and ended up disappointed. Eventually, I rolled my own, a SAX based (don't hurt me!) processor for mostly-XHTML templates. in your case, you mention a "transformation" that has to happen, but you don't say how the transformation is expressed, or if it can be done statically. if the transformations don't depend on any runtime information, you might be able to run the transformation offline, or if that's infeasible you can transform at runtime into a cache of some sort. in either case, XSLT performance (or lack thereof) won't be a problem. however, I've got to say that your requirements don't seem to be so strict that you should be ruling out XSLT, even if you have to run the transform online. my experience is that the performance problems in an XSLT approach are often due to the environment surrounding the transformation, and not the transformation itself. in any case, while XSLT will always add some amount of overhead, the win in terms of productivity can be pretty large. in my case, XSLT was sub-optimal, but not because of performance problems. a distinction often made on this list is that between implementors and users. but I'd guess many people deeply into XML are both: they are users of one or more XML technologies (DOM, SAX, XQuery, XSLT, etc.) but they are implementors of whatever system is making use of those technologies. and so they have their own base of users, and like all implementors they want to make life easy for their users. in my case, my users were going to be a number of designers. these are intelligent people, and could have (and sometimes actually have) learned enough XSLT to manage. but what I wanted was a system in which they could work in the most productive way they can, which means letting them use the tools they are used to using. in short, I wanted to let them come up with (X)HTML mockups, and I didn't want to break those mockups up into separate <xsl:template> sections when it came time to actually implement the system. the typical approach is that the designers come up with a mockup and give this to some sort of coder. the coder inserts whatever additional stuff is needed to replace the mocked up content with dynamic content, and also the various control (if, loops, etc.) constructs. the result might be JSP, ASP, Velocity, etc., but certainly not XML. Or HTML, for that matter. the designer cannot use the coder's result in making design changes, so the whole process has to start over again, and the pages end up a tangled mess of various languages. XSLT would make (and has made, when I've used it in this context) the situation much much better. but there are still at least two things that are irritating. the first I've already mentioned: the mockups usually need to be sliced up into XSLT templates, and the resulting stylesheet is not longer viewable as HTML. perhaps the process of moving from mockups to stylesheet could itself be automated, though. the other irritation is that it's too difficult to bind XSLT stylesheets to values in the "host language". the host might have access to a list of items, say, and I want to generate a <ul> in the stylesheet. this is doable, of course, but seems harder that it should be, and at any rate is dependent on the XSLT processor used. my reply has gone on a little longer than I expected, so I'll finish this up by mentioning TAL, which is used by Zope/Python and which is actually pretty close to what I ended up implementing. TAL is just HTML (or I suppose any sort of XML) with some additional attributes to control logic and dynamic value substitution. I think that the Cocoon people are experimenting with something similar as well. -- joe
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|