An idea to kick around, an HTML/XML friendly .ftlx syntax

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

An idea to kick around, an HTML/XML friendly .ftlx syntax

revusky
Today I was looking at Tapestry for the first time in a long time. I had
 looked at it before, not very deeply, and and had never really drawn
so many conclusions. You know, one wonders what one can get out of it
since the basic approach to the problem seems so different than that of
a plain text template engine like FM. (One side question that is not
very relevant to the conversation I want to start is why Sun bothered to
promulgate this JSF thing if Tapestry already existed and was a mature
solution? Is it just that they didn't invent it themselves?)

Clearly Tapestry templates have certain advantages, insofar as they can
be much more easily editable in an HTML/XML editor.

But basically, the whole thing does revolve around a simple little
"trick", which is that you can put an extra attribute (Tapestry uses
jwcid="...") in an HTML/XML element and most web-related tools will
ignore that attribute and leave it alone.

Of course, OTOH, the thing is tied very much to web-based formats, where
FreeMarker serves well for generating all kinds of text. Actually,
Tapestry templates have to be well-formed XML, it seems. OTOH, the basic
approach, AFAICS, could work with HTML generally, that's not well
formed, as long as you have a parser that builds up the DOM tree from
it, and figures out where implicitly closed elements are closed, and so
on. But Tapestry (perhaps for other reasons as well) requires well
formed XML as an input, i.e. XHTML. But we can do this as long as we
have a DOM tree to walk over.

But anyway, I got to thinking about all this and I don't see any
particular obstacle to basically using the same "trick" ourselves in an
alternative templating format.

Basically, why not just internally convert something like:

<span ftl="if user.isAuthorized()">
   blah blah
</span>

into:

<#if user.isAuthorized()>
   blah blah
</#if>

Or:

<tr ftl="#list basket.items as item">
   <td>Item: </td><td>${item}</td>
</tr>

into:

<#list basket.items as item>
 <tr>
   <td>Item: </td><td>${item}</td>
 </tr>
</#list>

Note that there is one major twist in the above, which is that in the
first example, with the if, the contents of the if directive were taken
to be what was inside the span element, yet in the second example, the
contents of the list loop were taken to be the entire <tr...> element,
not just what was inside.

But I figure one could differentiate the two cases by the presence of
the # character. Or the other possibility would be to use an extra
attribute maybe, that would determine whether to put the element into
the block or just the contents of the element. This is a little nuance
that can be resolved various ways, of course.

So, for example, the ftl pseudo-attribute could also be a user-defined
directive, so that:

<H1 ftl="@title">
   ${doc.title}
</H1>

could be translated basically into:

<@title>
   ${doc.title}
</@title>

I envisage this kind of FreeMarker template as being an alternative
.ftlx format.

Note that Tapestry, rather than using FreeMarker/Velocity/WebMacro style
interpolations, like:

${user.name}

uses something like:

<span jwcid="@Insert" value="ognl:user.name">John Doe</span>

But that mostly just seems silly. AFAICS, it is more straightforward to
just continue to use interpolations even in the .ftlx format.

I don't think this .ftlx format is really very hard to implement. Most
of the painstaking hackery involved would just be making sure that all
the line/col information is right so that the error reporting is as good
as with regular .ftl format. And that's just work.

I think we could have something like this working fairly quickly, and
offhand, I think it's desirable.

What do people think?

JR

P.S. I'm putting this on freemarker-user as well, so people there are
aware of it, but probably the discussion will be on freemarker-devel.

P.P.S. I doubt that .ftlx would be a complete replacement for .ftl since
a .ftlx would be heavily reliant on macro libraries that would be
#include'd or #import'ed. And the macro libraries would be written in
regular FTL. But, of course, the whole point of .ftlx, which is the
previsualization in HTML-oriented tools is probably kind of moot wrt
libraries, isn't it?

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: An idea to kick around, an HTML/XML friendly .ftlx syntax

Daniel Dekany
Monday, April 30, 2007, 11:15:15 PM, Jonathan Revusky wrote:

> Today I was looking at Tapestry for the first time in a long time. I had
>  looked at it before, not very deeply, and and had never really drawn
> so many conclusions. You know, one wonders what one can get out of it
> since the basic approach to the problem seems so different than that of
> a plain text template engine like FM. (One side question that is not
> very relevant to the conversation I want to start is why Sun bothered to
> promulgate this JSF thing if Tapestry already existed and was a mature
> solution? Is it just that they didn't invent it themselves?)
>
> Clearly Tapestry templates have certain advantages, insofar as they can
> be much more easily editable in an HTML/XML editor.
>
> But basically, the whole thing does revolve around a simple little
> "trick", which is that you can put an extra attribute (Tapestry uses
> jwcid="...") in an HTML/XML element and most web-related tools will
> ignore that attribute and leave it alone.
>
> Of course, OTOH, the thing is tied very much to web-based formats, where
> FreeMarker serves well for generating all kinds of text. Actually,
> Tapestry templates have to be well-formed XML, it seems. OTOH, the basic
> approach, AFAICS, could work with HTML generally, that's not well
> formed, as long as you have a parser that builds up the DOM tree from
> it, and figures out where implicitly closed elements are closed, and so
> on. But Tapestry (perhaps for other reasons as well) requires well
> formed XML as an input, i.e. XHTML. But we can do this as long as we
> have a DOM tree to walk over.
>
> But anyway, I got to thinking about all this and I don't see any
> particular obstacle to basically using the same "trick" ourselves in an
> alternative templating format.
>
> Basically, why not just internally convert something like:
>
> <span ftl="if user.isAuthorized()">
>    blah blah
> </span>
>
> into:
>
> <#if user.isAuthorized()>
>    blah blah
> </#if>
>
> Or:
>
> <tr ftl="#list basket.items as item">
>    <td>Item: </td><td>${item}</td>
> </tr>
>
> into:
>
> <#list basket.items as item>
>  <tr>
>    <td>Item: </td><td>${item}</td>
>  </tr>
> </#list>
>
> Note that there is one major twist in the above, which is that in the
> first example, with the if, the contents of the if directive were taken
> to be what was inside the span element, yet in the second example, the
> contents of the list loop were taken to be the entire <tr...> element,
> not just what was inside.
>
> But I figure one could differentiate the two cases by the presence of
> the # character. Or the other possibility would be to use an extra
> attribute maybe, that would determine whether to put the element into
> the block or just the contents of the element. This is a little nuance
> that can be resolved various ways, of course.
>
> So, for example, the ftl pseudo-attribute could also be a user-defined
> directive, so that:
>
> <H1 ftl="@title">
>    ${doc.title}
> </H1>
>
> could be translated basically into:
>
> <@title>
>    ${doc.title}
> </@title>
>
> I envisage this kind of FreeMarker template as being an alternative
> .ftlx format.
>
> Note that Tapestry, rather than using FreeMarker/Velocity/WebMacro style
> interpolations, like:
>
> ${user.name}
>
> uses something like:
>
> <span jwcid="@Insert" value="ognl:user.name">John Doe</span>
>
> But that mostly just seems silly. AFAICS, it is more straightforward to
> just continue to use interpolations even in the .ftlx format.
>
> I don't think this .ftlx format is really very hard to implement. Most
> of the painstaking hackery involved would just be making sure that all
> the line/col information is right so that the error reporting is as good
> as with regular .ftl format. And that's just work.
>
> I think we could have something like this working fairly quickly, and
> offhand, I think it's desirable.
>
> What do people think?

First of all, this not at all that simple as it seems:
- What's if you want to generate the name of an element dynamically.
- What's if you want to generate the name of an attribute dynamically.
- What's if you want to generate a whole list of attributes dynamically.
- What's if you have something like:
  <#if foo>
    <foo>
  </#if>
      ...
  <#if foo>
    </foo>
  </#if>

Now I do know the answers of these, and I'm sure you can find them
easily too, but the point is that it is not *that* simple as you have
depicted. Not only not that simple for you (the template language
designer/implementer), but also not that easy for the user. With
FreeMarker, where everything is just text, it is simply not a question
how to do these things.

Also, the thing that something doesn't confuse a Web browser or visual
HTML editor (or other schema specialized visual editor) doesn't worth
much. It is only useful for trivial templates, and then the existing
tools (Enhydra, etc) might as well good enough. But FreeMarker is a
power-template-engine. Users are expected to abstract away things to
macros and like. Look at a such template with visual editor is plain
useless. You usually wont see anything but a white page with some blue
box outlines in it (the div-s), and some distorted tables an dummy
headings. So this thing is not that useful as many would think at the
first glance.

Also note that these span/div/attribute tricks make editing any not
too trivial template quite tiresome. No to mention understanding those
templates. So if you want template that are well-formed, you better
try to utilize that any text outside tags that doesn't contain angle
brackets and and are will lave the XML valid. Like, this is both
valid:

  <ul><li ftl="#list foo as bar">...</li></ul>

and

  <ul>[#list foo as bar]<li>...</li>[/#list]</ul>


Another thing that you may fail to see (or not, I don't know...) in
these true XML template languages is that being a true XML template
language means much more than being syntactically XML. In fact, it
doesn't require that the templates are valid XML. It's about knowing
more about the output you generate than it is a string of characters.
I don't remember Tapestry very much, but as far as I remember it is
one of those languages that doesn't work with flat text, but with XML
nodes. And although not all (or rather neither) such languages
utilizes the potential behind this, there is a huge potential behind
this approach. Some of the new possibilities that open (not
necessarily in the order of importance):

- Now you can safely generate documents that use multiple name-spaces.
  The "everything is just text" template engines can't do it, unless
  there is a strict agreement regarding what prefixes are used for
  which XML namespace, and what prefixes must be declared with xmlns
  attributes where. Consider what an obstacle it is if you want to
  reuse macro libraries written by others.

- Really correct escaping. Because now you will know if you are inside
  and attribute (and how was it quoted), or inside CDATA section, or
  inside PCDATA.

- You can't create a template that generates non-well-formed output.
  Non-valid remains a possibility however.

- You can check the static parts of the template for typos. Like, typos in
  the element names, invalid attributes, invalid entry references, and
  so on. Like such, it will increase *a lot* the probably of valid
  output. And I bet that it hand-written templates (and that's where
  you usually end up with a power-template-language) making typos in
  the static part is at least as frequent than making typos in the
  dynamic. (Yes, one could check the output with a validator, but you
  know how convenient is that (like try to locate in the template
  where is the part that has generated the invalid part, also go and
  see how many people has validator installed), and that it will not
  check the parts of the template that were skipped due false conditions.)

- You can produce SAX events or DOM tree instead of plain text. It can
  be a very good thing if you need to process the output further (XSLT,
  whatever analysis)

- You can correct the indention of output. You can remove almost all
  extra white space. You can many such fancy things, because the
  template language really understands what it outputs.

(And combine it with a template language that also detect typos in
macro names and macro parameter lists at parsing time. Wouldn't that
be a Good Thing?)

After this, as you probably can guess one of the main point of my
re-FreeMarker mania is the idea of a true XML language.

> JR
>
> P.S. I'm putting this on freemarker-user as well, so people there are
> aware of it, but probably the discussion will be on freemarker-devel.
>
> P.P.S. I doubt that .ftlx would be a complete replacement for .ftl since
> a .ftlx would be heavily reliant on macro libraries that would be
> #include'd or #import'ed. And the macro libraries would be written in
> regular FTL. But, of course, the whole point of .ftlx, which is the
> previsualization in HTML-oriented tools is probably kind of moot wrt
> libraries, isn't it?

--
Best regards,
 Daniel Dekany


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel