[
Lists Home |
Date Index |
Thread Index
]
On Tue, 29 Mar 2005 07:06:11 -0800, Robert Koberg <rob@koberg.com> wrote:
> 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.
Fair enough, I guess I'm getting to the point where I just use XSLT:
in our situation I can manage the performance and I know I can do what
ever I need with the language...
> 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).
The guts of Cocoon use a SAX stream "compiler"; it captures the SAX
events for latter replay. Haven't really looked, but I suspect it
could almost be used standalone...
> >
> > - 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).
In our case, breaking the request down to a lot of granularity is part
of the trick to be able to use XSLT. Most of the resultant aggregated
SAX streams don't get regenerated. Of course, if any of them do, the
final XSLT (or more) still has to run, but even small amounts of
caching on the generation side seem to make a noticeable difference.
> >
> > 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.
Yeah, but I thought we already figured out how to avoid the parsing...
> >
> > 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? :)
Yes, that's why I was asking: did you consider them and reject them,
or is this not a Cocoon project, or ???
--
Peter Hunsberger
|
