OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML friendly runtime templating languages

[ Lists Home | Date Index | Thread Index ]

Peter Hunsberger wrote:
> On Mon, 28 Mar 2005 21:03:07 -0800, Robert Koberg <rob@koberg.com> 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? :)



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS