Re: Ideal tag syntax; what's your take on it?

Sorry to come to this thread a bit late...

We've got an internal document named "freemarker wish list" which digs 
into this topic in some detail. We'd considered doing our own template 
language to get around some of the limitations, but decided that there 
aren't enough hours in the day for that.

In general, we need an end-user/designer-friendly syntax, which can 
easily be extended.

Right now, you've got many different forms: [#foo], [@foo], ${foo}, 
different forms for functions, sometimes you can use positional params, 
sometimes only named params, ? for built-ins, . for non-built ins, etc. 
There are just two many variations.

I'd unify it all to use ${} syntax everywhere.

Hello, ${myName}.
It's ${myDate.todayFunction(format="MM/DD/YY")}
${if (happy)}
   Smile
${else}
   Frown
${/if}
$(list myTodos as todo}
   ${todo.display(aPositionalParam).someBuiltInFunctionHere()}
${/list}
${makeUpperCase}
   Some enclosed text
${/makeUpperCase}

Note that this syntax makes no distinction between official Freemarker 
commands and built-ins and custom ones. You could, theoretically, use it 
to override built-in functions (or even the "if", though you'd never 
want to do that). This way the user never has to ask "why do I have to 
use ?url here and .makeItAUrl there?"

In the case of the ${makeUpperCase} directive, the parser would have to 
be smart enough to know that some times a ${token} had a closing token 
and sometimes it didn't. I haven't tried to write the JavaCC for this so 
I don't know how tough it would be.

I wouldn't object to making it all [# /] syntax everywhere, instead of 
${}. I suppose you could always require a closing slash, [#foo/] or 
[#foo][/#foo], one or the other.

In another email, I'd love to talk about changes that should be made to 
the Freemarker object model. But that's for another day.



On 6/7/2011 12:46 PM, Daniel Dekany wrote:
> Ignore backward compatibility for a moment. What would *you* prefer?
> Or if you have no idea, what aspects of the current syntax bothers you
> the most in every day work?
>
>
> A bit of mussing from me (if you care)... The most modern form of
> FreeMarker syntax is like this:
>
>    [#assign x = 1]
>    [#if something]...[/#if]
>    [@myDirective]...[/@myDirective]
>    [@myOtherDirective /]
>
> Despite that the documentation doesn't push thins syntax at all, it
> has become very popular. That tells something.
>
> My personal(?) problem with the current situation is that while FTL
> (FreeMarker Template Language) has lost a lot from its SGML-ishness
> (HTML-isness) during its history, it kept some of the not-so-good
> things from it. So I'm afraid we have ended up with a mix that's too
> far from the ideal. Let's see:
>
> How FTL is not SGML:
>
> - For starters, the attribute syntax was never like in SGML or XML.
>    This is the cause of the most frequent mistake, where people try to
>    write<@foo x="${x}" />  instead of<@foo x=x />
>
> - 2.3 introduced those odd prefixes, "#" and "@" (instead of using
>    XML-ish name-space prefixes). I don't mind this in itself, not at
>    all. It's just not SGML-ish.
>
> - And now it doesn't even use<...>, but [...].
>
> How FTL is still similar to SGML:
>
> - You have to add a "/" to each empty-directive tag ([@foo /]), but
>    you don't have to add anything if nested content follows
>    ([@foo]...). Isn't that anti-intuitive and often inconvenient?
>    Nothing but SGML has this strange upside-down logic (I think).
>
>    Also, to complicate things... there are those who are more equal
>    than others. For a built-in directive you can write something like
>    [#assign x = 1] instead of [#assign x = 1 /], since FreeMarker knows
>    if they can have nested content or not.
>
> - You don't have to put comma between named arguments. In SGML you
>    have to quote non-trivial attribute values, so it isn't an issue
>    there, but I don't think any sane modern *programming* language
>    would do this with named arguments. [@foo x = a + 1 y = b + 1] is
>    just horrible. Luckily, you can write [@foo x = a + 1, y = b + 1] in
>    FTL, but you don't have to. (As a side note, we also have
>    ambiguities because of this:<@foo x = a! y = 2>  will be parsed as
>    <@foo x = a!(y == 2)>. Yeah, part of this is that FTL allows "="
>    instead of "==". That was a mistake too...)
>



------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2