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 ]

On Tue, 29 Mar 2005 07:40:04 -0800, Robert Koberg <rob@koberg.com> wrote:
> Peter Hunsberger wrote:
> <snip/>
> >
> > 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...
> 
> But, whenever you do a transformation, those SAX events need to be
> converted to the XSL processors internal DOM - a parse.

Hmm, ok, "parse" in the sense that you're converting one object
representation into another object representation, but not parse in
the sense that you're dissecting a character stream against a
grammar....  Really, at this point the same can be said for any
templating language, the fact that the internal representation is a
set of SAX events or a set of Java objects isn't going to make a big
difference if you're using Saxon to turn those events into objects. 
Admittedly, you mileage may vary with other XSLT implementations, but
personally I'd rather be wedded to Saxon than to some proprietary
template implementation.

Don't forget, a lot of this can be a lazy parse and a lot of this can
be a pre-compiled parse...

> 
> <snip/>
> >
> > Yeah, but I thought we already figured out how to avoid the parsing...
> 
> how?

You can prebuild the parsed XSLT for Saxon.  But I guess you're
worried about the input SAX side?  As I said above, I can't see a big
difference in feeding 25 SAX events to a precompiled template vs.
feeding 25 request objects (of some other form) to a precompiled
template.

> >
> >
> >>>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 ???
> >
> 
> I think cocoon is a cool project. The way our CMS works does not lend
> itself to recieve the benefits cocoon would offer. And, don't know if
> you recall, but I had fundamental disagreement with regard to the
> document function. I use the document function quite a bit and, unless
> it has changed, cocoon tended to discourage its use.

A lot of the internal pipeline handling and related code has changed
lately. I know there are some cases where calls to document hit the
cache for at least a couple of releases. If I recall correctly, it now
works in general, but you'd have to test...

-- 
Peter Hunsberger




 

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

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