Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML friendly runtime templating languages
 Peter Hunsberger wrote: > On Mon, 28 Mar 2005 21:03:07 -0800, Robert Koberg <rob@k...> wrote: > > <snip/> > > >>>>*I was wondering if there are other runtime templating languages out >>>>there that I am missing.* I am not including XSLT for runtime processing >>>>because of its need to parse the XML source for each transformation. > > > A couple of questions/observations: > > - depending on your environment you should be able to preparse the > XSLT and perhaps even build a "compiled" version of it; First, let me say I like XSL and use it all the time. I am simpply curious about other XML friendly templating languages that I might be missing. I gave the example of PXTL (http://www.doxdesk.com/pxtl/), a python templating language that was built with XML in mind. I had not heard of it or found it in my searches. I came upon Velocity and since it does not have angle brackets, it made it a nice fit with XSL/XML. The main problem with Velocity is its handling of whitespace. In our ASP CMS product we cache Templates objects. The CMS' transformations are pretty complex and we have not been able to get XSLTC or Resin's XSL compiler (or Gregor, for that matter) to work 100% of the time (there is always some low priority bug in their software). The CMS, in one case, generates XHTML and XHTML pages with Velocity templates. It aggregates or pre-generates as much as possible for the XHTML pages with Velocity (or JSP, PHP and soon PXTL) templates so that only what needs to be dynamic is left for runtime. The XML Source in the transformations is cached as Byte arrays. I tried caching SAX events, but Byte arrays seemed better. Either way, as has been discussed here recently, you either have to use a processor dependant DOM-like thing to get a pre-parsed Source or you have to parse. I like being able to test on and use different XSL processors (I usually tend toward Saxon 6.5.3, however). > > - do you know for sure that you have to regenerate the template output > each time or is there some level of cacheability? yes, there is app level caching (using the Resin servlet container and Jive Forums caching techniques) and page view level caching (i.e. paging links at the top and bottom of table views). > > We use pure XSL in Cocoon pipelines for a lot of heavy template > transfoormation. If we where doing light weight stuff I think we > could probably support several 100 requests per sec on a DB and Web > pair of servers. When you say highly performant, how restrictive is > your hardware environment? The project has a healthy budget. It is currently coming out of a pilot phase. Still, parsing the Source XML for each transformation will place limits that a templating language that does not need to parse would not. > > Finally, have you looked at any of the various Cocoon templating > solutions (which includes Velocity)? What? You don't remember me from the cocoon lists? :) thanks, -Rob 
|
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
|
|||||||||
