Re: [FMPP] Re: Freemarker 2.3.3 release, Java 1.5

[Daniel D. <dd...@fr...>]

Wednesday, June 29, 2005, 2:05:43 PM, Tilman Sommer wrote:

> I realize, this is not a FMPP topic but since we are in
> the middle of it already I just hope nobody minds
> discussing it a bit further.
>
> [snip]
>> The reason for not using XML syntax is that it would be very verbose.
>> Like, compare:
>> 
>>   <#if x>...</#if>
>> 
>>   <fm:if test="${x}">...</fm:if>
>
> Why not <fm:if test="x">... ?

You meant, why not <fm:if test="${x}">... ?

> Agreed, it is more verbose, but you gain a lot since you could use all
> XML tools then as well on FTL files.

Sure, if you follow a "standard" then you will have more 3rd party
tool... OTOH a lot of user don't like the verbosity of XML/JSP, and this
is an important reason why they prefer FreeMarker over them. I'm in that
camp too. Writing "programs" in XML is not just more typing, but the
result is harder to read... I lose in the sea of those redundant
delimiters (like "${ and }"). (SGML, whose subset XML is, was not
designed for writing programs, and it is bad in that. It was designed
for storing documents and other hierarchical *data*.) Now,
pluggalbe/configurable template language syntax is something that could
lead to satisfying everybody; chose the syntax the fits your job the
best. There is a progress in this direction, but... the problem is that
alternative syntaxes often require different semantic. Like, an XML
syntax assumes that all parameter is given by name. But some FreeMarker
directives use positional parameters too. Etc. Also, an XML syntax
require that you declare the types of the parameters, otherwise it can't
tell if in <@foo bar="123"> the value of "bar" is an integer or a
string. So I see it highly unlikely that pluggable/configurage syntax
will ever bring XML compliance.

> A normal XML parser would suffice for example, no need
> for a special FTP parser.

Well, FreeMarker authors don't care about that... they can write a
parser. I mean, they will not chose a different syntax just because they
are lazy to write a parser...

> I use jedit 4.2. It has a freemarker mode built-in, but this mode does
> not support code folding, also matching open-close pairs
> (<#list>...</#list>) are not indicated. I assume, this is because
> freemarker has no strict matching pair requirements as well-formed XML
> (e.g. <#include>).

It's not because of that. FreeMarker has strict requirements, just
nobody has written a good plug-in for it. Technically it is clearly
possible to "fold" an FTL file.

>> Also note that certain tasks can't be solved easily with keeping the
>> document well-formed XML, like try to do these:
>> 
>>   <p<#if forceAlignment> align="left"</#if>>...</p>
>
> See xslt:attribute
>
>>   <${elementName}>...</${elementName}>
>
> See xslt:element
>
>> Of course some special construct could be introduced for that (like in
>> XSLT), but then FTL wouldn't be a general purpose text generator,
>> because it had to parse the static-text parts too as XML.
>
> Maybe what is really needed for XML processing is a XML compatible
> extension of FTL (some kind of XFTL).  :)
>
>> Or what do you mean with "XML compliance" and why do you need that?
>
> I'm using it already - for me it is no show stopper. I just think for
> certain applications, it would be easier to deal with, similar
> to why XHTML came along replacing HTML sites more and more.
> You can now use existing validating XML parsers for example, etc.

My opinion about this whole thing is that for generating XML the ideal
template engine will be one that is not a flat text generator (like
FreeMarker or Velocity or WebMacro, which sees the output as a stream of
characters), but one that is specialized on XML, and generates an XML
document (i.e. a tree of nodes). A such template engine will not be
universal like FreeMarker, as practically you could use it only for
generating XML documents. But that's not a problem in itself... a Swiss
army knife is never as good as a specialized tool. FreeMarker will
always be a Swiss army knife.

-- 
Best regards,
 Daniel Dekany