Geir Magnusson Jr wrote:
Jonathan Revusky wrote:
Robert Koberg wrote:
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.
First of all, FreeMarker was never "repositioned" as an XML
transformation tool. It is, and always has been a general purpose
template engine. However, certain features were added to it that make it
a more adequate tool for XML processing, among other things.
In general, there seems to be some strange, confused thinking on your
part here. Let me clarify a few things:
First of all, starting from rudimentary first principles: any template
engine like FreeMarker or Velocity or WebMacro that can "merge" a java
data model with a template is *de facto* an XML transformation tool. A
DOM tree (or JDOM or DOM4J tree) is a java object model that can be
exposed to a template processing job.
By analogy, any general purpose text editor is also de facto an XML
editor, since the tool allows you to edit text and XML is just text.
OTOH, a general purpose text editor cannot be a "serious" XML editing
tool unless various special XML-related features are added. Similarly, a
general text editor cannot be a serious source code editing tool without
things like syntax highlighting and auto-indenting, among other things.
However, even so, even Microsoft Notepad is a source code editor, since
you can edit source code with it.
The above comments seem kind of obvious to me, and they don't strike me
as controversial, but I make them to provide an initial framework for
discussion. I shall continue:
A general purpose java templating engine can (and probably will) be used
to process XML, just as a general purpose text editor like emacs or vi
can (and will) be used to edit XML. Now, whether the tool incorporates
special features related to working with XML is entirely another matter.
Now, it is my view that, in its range of likely usage, a template engine
like FreeMarker or Velocity or Webmacro will often be used in
conjunction with an XML data model, so there is a strong case for
introducing the necessary functionality to handle these use cases
properly -- in a "serious" manner.
Now, even accepting (for the sake of argument) that a tool that is
completely specialized for XML (as opposed to general templating) such
as XSLT is better -- *if* all you're doing is processing XML, there
would still be substantial interest in XML-related features in a general
template engine. For example, continuing the text editor analogy, I
could accept that a specialized XML editor is going to be the best tool
for editing XML, but if I am a coder who uses emacs, say, for editing
all kinds of source code, I may prefer to use emacs for editing XML as
well. Thus, there would surely be (and is) interest in an emacs editing
mode specialized for editing XML.
You see what I mean, right? Similarly, if I use FreeMarker (or Velocity)
for all kinds of text generation tasks, I may want to use it for
XML-processing ones as well.
Given that the tool is likely to be used for XML transformation, one
might as well be serious about it and introduce the features people need
in that specific application space.
The point of DVSL is to have a separate tool to handle the XML
processing,
Well, whether you classify DVSL as a "separate tool" or as a Velocity
add-on or whatever seems somewhat arbitrary.
FreeMarker's declarative XML processing consists of two new directives
<#visit...> and <#recurse..>, as well as a built-in wrapper to expose
DOM objects to a template in an intuitive way. Also, some XML-related
built-ins were added to the core.
Now, we could have added the visit/recurse directives and XML-related
built-ins as a separately downloadable macro library along with the DOM
wrapper classes. This was even discussed as a possibility at the time.
However, finally everything was added to FreeMarker's core
functionality. In the end, this was my call, and I definitely feel now
that we made the right decision. This is a while back, so it is hard to
recall everything that was going through my mind then, but I am pretty
certain the reason, was, quite frankly, specifically to avoid what you
see here wrt this DVSL thing.
Since this declarative XML processing functionality was added as a core
part of FreeMarker, and there is absolute clarity that we are committed
to supporting this as core functionality. It is not abandonware. If I,
Daniel, and Attila drift off and other maintainers take our place, those
people will not be able to say, as Will recently did, that they are not
supporting this functionality. Visit and recurse, for example, are core
directives in the language now, just like if/else.
The result is that there is absolute clarity in our camp about what is
going on, whereas, frankly, wrt DVSL and Anakia and what not, it is all
extremely murky and unclear whether there is any willingness on
anybody's part to support or maintain these things.
<snip a bunch of nonsense about how we copied Velocimacros, already
addressed that>
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.
From my perspective, this is *such* a bizarre, confused comment.
Generating human-readable output, reports or whatever, from an XML data
model combined with some kind of template *is* templating, just the same
as editing XML *is* text-editing. To be a good XML editing tool, an
general purpose text editor needs to add certain features, and to be a
good XML processing tool, a general purpose templating tool needs
certain special features.
The difference between FreeMarker and Velocity in this regard is that in
FreeMarker, the specific work to make FreeMarker a good XML processing
tool has been done. In Velocity it basically has not been done. Some
initial stuff was done, Anakia and then DVSL, but then left in a
completely abandoned half-baked state.
Since the functionality in FreeMarker was added as part of the core
product, there is clarity about it being supported in the future. The
whole situation wrt Anakia and DVSL is very murky and unclear.
I think it's obvious that this is just highly undesirable. Given this
lack of clarity, I cannot easily imagine that a rational, well informed
person would really want to touch DVSL, say, with a ten-foot pole.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org/
declarative XML processing with FreeMarker,
http://freemarker.org/docs/xgui_declarative_basics.html
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]
