Jonathan Revusky wrote:
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.
I'm not sure that a template engine should be a "serious XML
tranformation tool", but I suppose that's the beauty of software
marketing - you can always just reposition if there isn't uptake in
current incarnation.
The point of DVSL is to have a separate tool to handle the XML
processing, and just invoke velocity templates for output formatting.
The intent was to replace anakia, which is really just a procedural
approach to rendering our xml-based documentation system.
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.
If I recall, it took you quite some time to copy the lame velocimarco
functionality for freemarker ;) I'm sure your implementation was vastly
superior, but you'd be a moron if you didn't address deficiencies in the
thing that you copied. That's how science and technology progresses,
right? "Stand on the shoulders of giants", and all that. Velocimacros
wasn't an original idea in itself, but was new to templating solutions
at that time. Man, how the years go by.
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.
The intention of velocity is just to use it for formatting... I like
the XSLT model, but can't stand writing output (HTML) in a language that
looks just like it (XSL). Personal itch, I guess.
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 would be surprised as well. But were I doing serious XML processing,
I wouldn't be using a templating engine for anything but templating.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
