Robert Koberg wrote:
Geir Magnusson Jr wrote:
The velocity aspect - templating - is the same. What it's meant to do
is simply use the declarative model of XSL (which *is* complicated)
and let you use Velocity to do the rendering.
Hi,
I just had a look at this again after using Velocity for a year or two.
I can see some way to use this inside a Velocity template/page very
nicely. I believe I know XSL 1.0 pretty well. I can see how some things
in Velocity proper can replace some things in XSL so they do not need to
be repeated there. I have some quick questions questions off the top of
my head:
- how are namespaces handled? how do you declare them? Is XPath fully
supported (uses Jaxen perhaps?)?
- are there modes and named templates?
- can you do something like:
#if ($foo)
#match("foo")$context.applyTemplates()#end
#else
#match("*")$context.applyTemplates()#end
#end
- can you use the XML nodes in a conditional. For example say I have a
source like:
<foo bar="something"/>
Can an if be like an XSL if testing the existence of the bar attribute
like:
#if (@bar)
do something...
#end
best,
-Rob
Robert, a few years ago, I looked quite seriously at the issues involved
in enhancing FreeMarker to become a serious XML transformation tool. At
that time, FM had some XML processing capabilities, approximately
analogous to Anakia, but I had no illusions that this made it a feasible
XSLT substitute.
Much of the motivation behind the the new features that were introduced
in FreeMarker 2.3 was to make it an adequate tool to build an XML
transformation tool on top of. I mean, besides the obvious ones of the
visit/recurse directives, features like much improved whitespace
handling, significant improvements to the macro system, with the
introduction of namespaces and macros with nested content. Without these
things, FreeMarker could never be a serious XML transformation tool.
Since Velocity never did add these features (or hardly anything else) it
seems apparent to me that Velocity itself is not adequate infrastructure
on which to build a serious XML transformation tool.
Just for starters, given Velocity's deficiencies in whitespace handling,
any recursively complex XML transformation will output oodles of
extraneous whitespace. That could be tolerable, I suppose (though I
don't quite know why anybody *should* tolerate it) but the real killer
is the lameness (I can't find a better word) of Velocity's macro system.
There is no notion there of scope/visibility of macros or variables.
Everything just seems to live in some big global namespace where local
variables and included macros and so on can happily clobber one another.
And you combine this with the fact that Velocity macros pass arguments
by name rather than by value probably leads to some major problems as well.
I believe that anybody building much more than a toy app will eventually
find himself tearing out his hair with these limitations.
Even if DVSL were to become more actively developed, given the
deficiencies in Velocity itself, it has no prospect of being a serious
XML transformation tool.
If you look at alfresco.org and statestep.com, you will see some
professional tools that leverage FreeMarker's XMl processing
capabilities. I have serious doubts whether anybody is currently using
Velocity in conjunction with DVSL for serious XML processing tasks.
I suppose all of the above could be construed as highly negative and so
on. But really, as a fellow developer, I think I'm doing you (and
anybody else reading this) a good turn. I am discouraging you from
wasting your valuable time and energy on something that is clearly a
dead end.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
