Re: XML Syntax with Freemarker?

Saturday, July 31, 2010, 7:50:34 PM, Michael Cervenak Ahern wrote:

> Hi Daniel,
>
> Thanks for the quick response - I admit defeat on the fully
> conforming XML syntax.  Reading through your comments here and the
> archives in regards to GXP I see what you mean.  At some point it
> breaks down unless you are willing to fully split control flow logic
> out of the template language - at which point you have Wicket and lose simplicity.  Oh well.
>
> What got me going down this path in trying to generate XHTML
> markup.  At least for the book examples taking the top of page
> [#directives] and converting them into XML directives <?ftl-...?>

Indeed, you can't have character data before the root element. (OTOH
in most cases you can avoid using the #ftl directive.) The same
problem occurs with #import and like, as normally you would put these
to the beginning of the template. So maybe instead of <?ftl...?> and
like, doing something like this would be better:

  <!--#
  [#ftl ...]
  [#import ...]
  ... etc. Whatever initial FTL code comes here.
  -->
  <root>
    ...
  </root>

And then the TemplateLoaders should remove the "<!--#" and the
corresponding "-->", but keep the line-break after them (so the line
numbers in error messages will remain intact).

> seems to allow simple templates to be successfully loaded by an XML
> viewer... although I can't imagine that there is not some valid
> Freemarker syntax that  breaks the XML-ness.

Of course it's easy to create cases where the template is proper FTL
but not well-formed XML. The bigger problem is when there is something
that you can't write on a way that is well-formed XML. In those cases
however, you can move out the problematic part to a macro that is
stored in another file; awkward. (Plus, #ftl and #escape simple can't
be moved out, as they have effect on a lexical scope.)

To solve this, maybe "<!--#" should become part of the FTL syntax
starting from 3.0. Also we have the problem that the logical AND
operator can't be written as &amp;&amp; or &amp;, only as && or &.
Unfortunately fixing this is not 100% backward compatible... so this
is again something for 3.0. (If there will be a 3.0 anytime soon... if
not, then I suppose there will be a 2.5 instead.)

> This should be easy enough to find out using with a custom template
> loader - thanks for pointers.
>
> Regards,
> -Mike
>
> On Sat, Jul 31, 2010 at 3:44 AM, Daniel Dekany <[email protected]> wrote:
>
> Saturday, July 31, 2010, 5:17:05 AM, Michael Cervenak Ahern wrote:
>
>> Ok,
>>
>> So this is a question / comment for the floor.  A problem that has
>> been bothering me with Freemarker and that is that you can't quite
>> create an Freemarker template that is also a valid XML document.  If
>> you are using it as a general text templating solution it is not a
>> problem - so far in our project we are using it for email templates.
>>
>> The problem area that had caused me to initially investigate the
>> project though is in the generation for providing plug points for
>> customer content customization of HTML markup.  In this role, I have
>> been looking at ways to reduce / catch developer and customer
>> errors.  One easy way to do this is if it supported an XML markup
>> notation.  One can almost do this with the square bracket notation
>> if you set square brackets as the default... however, I have noticed
>> that there are a couple of times where you still need to put
>> directives at the top of the template which break the XML ness.
>>
>> So to prove my point on catching errors; just take a look at the alternative syntax page itself:
>> http://freemarker.sourceforge.net/docs/dgui_misc_alternativesyntax.html
>> In this example it is missing (and I belatedly starting take notes so I apologize for any omission):
>> - 1 x </th>
>> - 2 x </td>
>> - 2 x </tr>
>> - 1 x </p>
>> - 2 x '/' in close element tag
>> I know this was a hastily written example - and I'd spot the error
>> (I hope) at runtime in the browser;
>
> These are not errors, as the template uses HTML, not XHTML. End-tag is
> optional for these elements in HTML.
>
>> but all of those errors would have been flagged by my syntax checker
>> while editing. Getting rid of the directives at the top and plopping
>> this in an XML editor still leaves one syntax error with the
>> placement of a [/#if].
>
> The #if is also used properly in the example; as they are not XML
> tags, but FTL tags, they don't need to nest properly with HTML tags.
> (Anyway I also don't like this kind of solution, because you repeat
> the condition expression, but that's another topic...)
>
>> As such a full blown XML markup does feel in order.
>>
>> Anyhow this is a super long winded question, but is there any
>> thoughts / plans around this?
>
> As of plans, there is practically no chance FreeMarker will ever be
> XML/HTML aware, or support an XML syntax. Like, first we had to push
> out 3.0, which is much less radical and much closed to completion, and
> still...
>
> As of thoughts (if you are still interested after the "plans"
> sections), I believe that a template language on the field where
> FreeMarker plays, should be (X)HTML-aware, and so even spot typos in
> HTML element names and like. Also it would need special flow-control
> instructions for making elements conditional with keeping their
> children, also there should be built-in ways to add/remove HTML
> attributes, etc. But as of using XML-syntax for the templating tags,
> it's IMO a PITA (and not doing that is one of the important selling
> points of FreeMarker over JSP), given the ridiculously verbose syntax
> of XML when used for a programming languages:
>
>  <t:if test="${exp}">
>
> VS
>
>  [#if exp]
>
> Surely using XML syntax editors could spot *some* of the typos in the
> template tags too, but I'm not sure that worths all the extra typing
> and the resulting visual bloat. If you only want to spot the errors in
> the static parts with an XML-editor, the best thing you can do is keep
> the templating constructs look like XML character-data, and that you
> can almost achieve with [#...]. Just almost, because you are in
> trouble if you want to make a HTML attribute conditional, or an
> element name to be a variable, etc. But there are work-arounds for
> those too... yeah, they are kind of awkward, but still.
>
>> I know Freemarker will never be GXP - however GXP appears dead...
>> long live Freemarker
>
> (Frankly, I'm puzzled how still no Java template engine of this kind
> appeared in so many years that mops the floor with FreeMarker. I mean,
> would any of us long-time "FM admins" here design an engine now, it's
> virtually impossible to do something that's not better than FM. I
> really just came here (like 10 years ago?) to help writing docs and
> suggest a few features that I needed (as I don't have time to write my
> own engine), and look where it went... And now I will be the one who
> has to have the bad conscience!   That's why I always have this
> burning desire to "beat" FM myself, but not the time/energy it
> seems...)
>
>> One thought around prototyping this once things quite down is to use
>> an XSL template and a custom template cache to look for '.xftl'
>> files that are transformed into standard .ftl files to rather than
>> cracking open the template parser code.
>
> That's actually the question of writing a TemplateLoader
> implementation (and the XSLT, of course). Only problem with it is that
> the error messages will be hard to understand, since those will refer
> to the already transformed templates.
>
>> While I'm still a ways from finding the time to do this - have there
>> been any thoughts in the past/present around what such a syntax
>> would look like?
>
> Yes, I think you will find some discussion in the archives.
>
>> Thanks in advance,
>> -Mike
>
> --
> Best regards,
>  Daniel Dekany
>

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm