[
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? :)
thanks,
-Rob
|
