Re: XML Syntax with Freemarker?

Wednesday, August 4, 2010, 6:15:48 PM, Jeremy Chone wrote:

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

Note that while the "hash" type doesn't support non-string keys
(because historically it was just a dictionary of variables, and
variable names are strings), the Map.get method, if(!) the object
wrapper exposes the "get" method, works fine with BeansWrapper-based
object wrappers. But wrapped Map-s usually don't expose their methods,
because then the method names would interfere with map entry keys
(name clashes, etc.). And that's because FreeMarker doesn't have a
separate name-space for methods and for Map keys, while Java has it.
(Actually Java is rather mean with script languages in this regard: it
uses at least 4 name-spaces, all you just want to naturally expose
with the dot operator, like anObject.aSubVariable: JavaBean
properties, fields, Map keys, methods.)

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

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