Robert Koberg wrote:
Jonathan Revusky wrote:
I've heard this before. I think you must mean that FreeMarker's syntax
-- the use of <#...> as delimiters -- confuses XML-oriented editors.
It does not confuse them. It is just wrong for XML.
Well, yes, but a raw FreeMarker template is not an XML file. You're
editing a non-XML file in an XML editor and saying that FreeMarker is
the problem when this doesn't work. If you used FreeMarker (or Velocity)
to generate java source, would you expect the raw template to be a valid
java source file?
Or are you saying
freemarker understands things it was not specified to handle?
Hold on. What are we talking about? In the above, I'm saying that if you
try to edit a raw FreeMarker template in an editor that is meant for
HTML or XML, it "could" be a problem. There is nothing for FreeMarker to
"understand" at this point.
But it was for this reason that the alternative syntax was introduced:
[#if x==y]....[/#if]
as a replacement for:
<#if x==y>...</#if>
that the latter might confuse an XML-oriented editor XML-oriented tool
is true, but it's not inherently a problem with FreeMarker, because a
FreeMarker template is in FreeMarker template language, not XML.
(BTW, if you want to play with FM using the alternative syntax, you need
the latest build from CVS. But it's perfectly stable, it's only a change
to the delimiters in the lexer. The same AST is built, so you know...)
Because, of course, generally, the claim is not valid: there's no
general need for a template to be well formed in its output format.
For example, it would be surprising if a raw template used to generate
Java code was itself compilable java.If you're generating XML, the key
thing is that the output be well formed XML and a lots of people use
it for that.
Well, I use Velocity in content chunks that are transformed by XSL to
whatever end result. I need the source to be well-formed.
Oh, okay.
But basically, correct me if I'm wrong, but you're using a two-pass
approach XSL->Vel->Final output because Velocity is not powerful enough
on its own to do the full job. Meanwhile, certain kinds of things are,
if possible in XSL, extremely annoying compared to a template engine
like Vel or FM.
You have a text generation problem that neither tool, XSL or Vel, is
quite right for, so you chain the two. And therefore, you want the
template, besides being correct VTL (which it must be) to also be
correct XSL.
Now, what if I told you that FreeMarker is *probably* (I hedge because I
don't know exactly what you're doing) powerful enough to do the whole thing?
If this piques your curiosity, look at:
http://freemarker.org/docs/xgui_declarative_basics.html
or the entire section:
http://freemarker.org/docs/xgui.html
But, anyway, FYI that was just addressed. You can now use an
alternative syntax where instead of:
<#assign x = 3>
you write
[#assign x=3]
OK. I guess I would trust velocity at this point.
??? You mean you wouldn't "trust" FreeMarker? Why on earth not? Look at
Velocity's bug tracker and look at ours. (We're like RAID. We kill bugs
dead. :-))
etcetera. So it's now just as XML-friendly as Velocity is. Though,
with the difference that FM is a powerful XML transformation tool and
a viable replacement for XSLT.
Is freemarker a standard (sorry, I know the answer :)? Does freemarker
have as many/more implementations as there are XSLT processors? I highly
doubt freemarker has run into the cases that the more established XSL
processors have.
Hold on, Rob, you're not playing games with me now, are you? You're
asking questions that you know the answer to, right?
But, okay, just in case you don't know:
FreeMarker is not a standard and does not have multiple implementations.
However, Velocity is also not a standard and does not have multiple
implementations either. And you're relying on that as a piece of your
system.
In any case, independently of multiple implementations and XSL's
standard-ness, it is likely that, from an engineering POV, you will
achieve a more simple, reliable, maintainable software system if you are
able to use a single text transformation tool for a job rather than
chaining two different ones together.
Is that an unreasonable conjecture?
Jonathan Revusky
--
lead developer, FreeMarker project http://freemarker.org
Velocity-FreeMarker comparison page: http://freemarker.org/fmVsVel.html
>
> wha
-Rob
Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
