Re: XML Syntax with Freemarker?

Yes, I can see the impedance mismatch.

On Wed, Aug 4, 2010 at 2:20 PM, Daniel Dekany <[email protected]> wrote:

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


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