Re: XML Syntax with Freemarker?

Thanks for the update Daniel. Looking forward for the 2.4.

Yes, the full Map support is pretty wanted. Right now, I have to have "UI
only getters" on my bean to convert any Map gettters to <String,Object>.

Jeremy,




On Tue, Aug 3, 2010 at 1:21 AM, Daniel Dekany <[email protected]> wrote:

> Monday, August 2, 2010, 2:52:06 AM, Jeremy Chone wrote:
>
> > +1 for this one: "I still like the idea of an API rewrite and
> > breaking backwards compatibility to fix some of the pain points."
> >
> > For me, the two biggest painpoint are "null support" support for
> > full MAP support (right now, <String,Object> seems to be the only
> > thing supported). Also, I would love to have GAE support in the main
> release.
>
> 2.4 and later will be GAE-compatible (plus we already have 2.3-gae for
> a while). Note that 2.4 is pretty much like 2.3, the version number
> increase is mostly only necessary because GAE-support breaks
> backward-compatibility a bit. (What we earlier called 2.4 (which had a
> preview release looong ago) is now 3.0.)
>
> 3.0 is null-aware, but it's release schedules are unsure at best.
> However, I think the null-support is easy enough to backport, that in
> the sad case where 3.0 doesn't make it, it can part of a 2.5 or
> something.
>
> Non-string key support needs a new type in FTL (so it would affect the
> code on quite a few "deeper" places), but at least we can call that
> new type "map", instead of "hash", and then make "hash" deprecated. So
> I think as far as the object wrappers doesn't use that new type by
> default, this can be added without waiting for a 2nd version number
> increase. (Or do I miss something here?) However, I haven't seen any
> commits yet that addresses this. /-: But the importance of the issue
> is recognized.
>
> > jeremy,
> >
> >
> > On Sun, Aug 1, 2010 at 8:16 AM, Brian Pontarelli <[email protected]>
> wrote:
> > I use FM for so much stuff like XML, HTML, JSON, text emails,
> > XHTML, JavaScript, properties files, yaml, etc that it any other
> > solution (Wicket, Sitebricks, GXP, etc) wouldn't work. FM really has
> > a great design from the template perspective. I still like the idea
> > of an API rewrite and breaking backwards compatibility to fix some of the
> pain points.
> >
> > -bp
> >
> >
> >
> > On Jul 31, 2010, at 1:40 PM, Jeremy Chone wrote:
> >
> > Personally, I like that freemarker is orthogonal to XML. It allows to do
> things like
> >
> > <div class="[#if fancyLook]fancy[/#if]" > ... </div>
> >
> > I have been a big fan and user of freemarker for quite some years.
> > The problem with all the other template languages is that they are
> > trying to be XML and/or jsp based. JSF s a great example of
> > over-designed templating engine, which at the end reduce
> > productivity and lower output quality.
> >
> > Freemarker is very easy to customize and extends, and its
> > "adhoc-style" allows to inline macro about anywhere. This is a big
> > productivity boost compared to more [overly] structured template engines.
> >
> > Interestingly, even with the low release cycle, Freemarker is still
> > the best templating engine out there (IMO). The responsiveness of
> > this distribution list really has giving me me comfort that despite
> > its low release cycle, Freemarker is still a safe bet.
> >
> >
> > Jeremy,
> >
> >
> > On Sat, Jul 31, 2010 at 10:50 AM, Michael Cervenak Ahern <
> [email protected]> 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-...?>
> > 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.  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
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> > _______________________________________________
> > FreeMarker-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/freemarker-user
> >
> >
> >
> >
> > --
> > Jeremy Chone
> > +1 415 699 9912
> >
> >
> ------------------------------------------------------------------------------
> > 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_______________________________________________
> > FreeMarker-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/freemarker-user
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
> > _______________________________________________
> > FreeMarker-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/freemarker-user
> >
> >
> >
> >
>
> --
> 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
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>



-- 
Jeremy Chone
+1 415 699 9912

------------------------------------------------------------------------------
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

_______________________________________________
FreeMarker-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freemarker-user