Robert Koberg wrote:
Hi,
I find quit a few people are scared off by XSL, but I don't see the benefits
of Freemarker:
Well, the benefits would be simplicity, that the tool is simply more
accessible to people. I assert that more people will become more
productive more quickly using FreeMarker (and I mean specifically FM's
new XML-transformation capabilities) than with XSLT. However, I am
reluctant to enter into a long dissertation as to why I think it would
be that way.
Whether tool X really is easier for people to become productive with
than tool Y is a purely empirical question that can only be resolved by
practical experimentation.
Moreover, I want people to try it for themselves, so I see no point in
launching into a long attempt to explain the benefits.
<if session.msg><call draw_tooltip()>
<else>
</if>
<call draw_icon_rows("5")>
That's very old FreeMarker code. It uses an older syntax that still
works but has been deprecated. In current FM syntax, the above would
look more like:
<#if session.msg?has_content>
<@draw_tooltip/>
<#else>
</#if>
<@draw_icon_rows 5/>
First, you still have what most people complain about - the angle brackets.
Well, I don't see the angle brackets as being a problem per se. In fact,
if you assume that your target audience is at least familiar with HTML,
it makes sense to have your template language be HTML-ish. It simply
looks familiar and you can initially introduce (via what is admittedly a
white lie) various FreeMarker directives as sort of additional HTML
tags. In any case, the syntax of a language is really its most
superficial aspect. I basically took over the FreeMarker project about
16 months ago and, at that point, it already had a history and its
syntax which used the angle brackets. I have been the principal
maintainer of the project over the various 2.x release cycles, 2.0, 2.1,
2.2, and now 2.3. 2.3 introduces some interesting XML-related features
that I want to get people interested in trying.
Second, it is not close to being XML so you can't check for well-formedness
or validity.
Well, this point is really a non-issue, you know. FreeMarker templates
are quite unashamedly *not* XML, so there is simply no issue of checking
them for well-formedness or validity -- no more than checking whether a
perl or java source file is well-formed XML! A FreeMarker template is
written in FTL (FreeMarker template language) and must therefore be
correct FTL. We have a plugin for the eclipse IDE that works fairly
well, for example, that parses FreeMarker files and gives you the line
numbers where a parsing error occurred (if one did) and so on. And it
tells you where the error is. But by that, I mean an error in FreeMarker
syntax.
We use HSphere site hosting software (soon to change...). They wrote their
control panel templates in Freemarker.
Yeah, it looks, just from the code snippet you quoted, like they used a
very old version of FM, like 1.5.2. As I said earlier, the FreeMarker
2.x releases are the ones that are my fault.
Let me state quite clearly that what I am talking about here is entirely
new functionality added in the FreeMarker 2.3 cycle for
declarative-style XML processing. For example:
http://freemarker.org/docs/xgui_declarative_basics.html
So, this functionality that I'm telling the list about was not part of
the obsolete FreeMarker version which you are familiar with.
The language itself was not hard to
pick up but the templates were written without understanding of how to
separate content/data from presentation. It made trying to modify the
templates ridiculously more difficult then it should have been. Perhaps
simpler templating languages can be learned faster, but they lead to sloppy
work that is next to impossible to reuse.
I am not sure of the chain of reasoning above. You seem to be implying
that if the HSphere people used XSLT for the same task, they would have
had something more maintainable rather than the mess you describe. Why
is this so? I put it to you that it is entirely possible that the very
same people, had they used XSLT instead of FM would have come up with
the same sort of unmaintainable mess. One doesn't know for sure, but
that strikes me offhand as the most likely result of the experiment.
I guess that will be there in any 'templating' language, but the more you
stick with XSL the more you are steered toward the ideal - separation of
concerns.
Well, that's an interesting claim. My initial reaction is one of great
skepticism. By what mechanism does this occur? How does sticking with
XSL cause people to be steered towards a more correct design?
To sum up, yes, XSL is more difficult for many people to pick up naturally,
but worth the effort.
Well, the statement of mine that Wendell Piez took issue with was that I
asserted that XSLT does not come naturally to most people. You, on the
other hand, do seem to be in agreement with my position on this.
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
New XML-processing features in FM 2.3, http://freemarker.org/docs/xgui.html
Best,
-Rob
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list