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

Thursday, June 30, 2011, 10:05:10 PM, Chris wrote:

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

(Same problem here... After using FM for a decade surely I have ideas
how to do it differently, but then I always realize it would be a
several months of full-time (and I mean programmer's full-time, i.e.
6x12) job.)

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

There are too many, but it's quite tricky to eliminate some of them...

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

That way there can be naming clashes between that standard functions
and the data-model. Which one has the priority? Technically, giving
priority to the built-ins may seems to be the best answer, however,
then you can't extend the template language without breaking existing
templates. If the data-model has priority, then you still has a tricky
case with existence checks (i.e., you break backward compatibility
again, even if it's a less frequent problem). So I'm not sure how to
make this problem manageable, merging the data-model and the stuff
that's part of the template language. I have only went so far as
uniting all kind of directives (# and @) and built-ins (?) into a
single concept (called toolbox methods). That's already a huge
simplification both for the users and the template engine developers
BTW.

Merging interpolations into the same concept... technically the are
merged, as ${x} was really just like [#echo x] or like (note: not in
FM, because of #escape), but the syntactical distinction often
remained useful for eliminating parentheses. Like, consider if method
calls are like [#foo 1, 2]. Here I have eliminated parentheses, as it
wasn't [#foo(1, 2)]. That was possible because after the "[#" I
already know that it's not an interpolation, but a method call. If the
interpolation syntax is like [#x] too, then there's an ambiguity: do I
print the value of x here, or call the x method and print its return
value?

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

It's plain impossible, unless the parser has access to the definition
of all those things that you refer to by name. However at least the
data-model is a runtime thing, so it's not possible. And even if the
parser can do that, because you were super-smart and so on, how could
the user do the same? He or she looks at ${foo}, and wonders if it's
just an interpolation, or a call to "foo", and if it's the last,
should (s)he look for a "/foo" too?

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

I would prefer if there's no extra character needed if you don't have
nested content. Instead there should be one when you *do* have nested
content. Like (using your syntax for now, kind of):

${bar}  <-- no nested content
${foo (1, 1):}  <-- ":" indicates that nested content follows
  ...
${end-foo}

> 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
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

-- 
Best regards,
 Daniel Dekany


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