"Schnitzer, Jeff" <[EMAIL PROTECTED]> writes:
> Velocity produces text that must be parsed to perform XSLT transforms.
> This new approach starts immediately with SAX events. Unlike a
> hypothetical "saxify", it doesn't require fully navigating the source
> object graph. Cool.
yes, I think so too. in fact, I'd say that this might be the biggest
win to this approach.
> The downside is that it introduces yet another templating language
> syntax. What about borrowing the syntax of XSLT? Presumably your web
> developers are already using XSLT to handle the outgoing sax events, it
> would be nice if they could leverage their existing knowledge.
I agree, and have given quite a bit of thought to exactly this
solution. but I don't think it'd work, at least not in a way that
would meet my initial requirements.
first, XSLT is needlessly verbose. I don't want to have to say
<xsl:value-of select='...'/>
every time I want to refer to a value.
second, and more importantly, it doesn't really solve the problem.
the key piece is something to allow you to refer to
objects/properties/methods from within the template. that is, you
want to be able to easily cross the boundary between the template
language and the "host" language. I could think of only two ways of
doing this in XSLT
1) write an XSLT extention function, to be used as in
<xsl:template match=''>
...
<a>
<xsl:attribute name='href'>
<xsl:value-of select='ext:expr(model.price)'/>
</xsl:attribute>
...
</a>
</xsl:template>
but that's waaaaay too verbose, and doesn't really solve anything
anyhow, because you've still got a mini-expression language
(e.g. "model.price").
2) domify the graph of potentially reachable objects, and use the
document() function plus a suitable URL resolver to find access the
objects from the stylesheet.
that also seemed too awkward. the bottom line is that the expression
language used in XSLT is XPath, which is an incredibly powerful and
useful language, if you happen to be applying it to something that
fits with the XPath data model. this didn't seem to be the case to
me at the time, although XPath 2.0 looks like it might come closer.
I wanted something that would be both fast (execution-wise) and
relatively easy to explain to programmers/designers of moderate
experience level. I've been pretty happy with it so far on both
counts. the app in question exhibits snappy performance (although I
have done no testing to validate this) and people have picked up on
the ideas pretty easily.
on a somewhat off-topic note, I'll say that when I first considered
doing this my instinctive reaction was: "Please! Not another Java
web framework!". But on further consideration, I don't think this
critisicm was really valid. Really, it's just a recycling/repackging
of various systems already available (Maverick, OGNL, "SAX"). More
importantly, it used to be, back before I became someone who designs
applications exclusively for the web (sigh), that I wasn't afraid of
designing application-specific "little languages". This approach
was considered a powerful tool for solving problems in a general
way.
anyhow, maybe the best thing would be for me to clean things up, put
the code+examples someplace public, and let people take a look. I'll
do this and let the list know when it's available.
--
joe
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
[INVALID FOOTER]
