Re: [Freemarker-devel] Ideal tag syntax; what's your take on it?

Friday, June 10, 2011, 8:36:15 AM, Denis Bredelet wrote:

[snip]
> The real advantage of Velocity syntax is that it uses line-ending as
> a delimiter. That sometimes complicates white space handling but it
> is visually nicer.
[snip]

AFAIK, you don't have to break the line after Velocity directives.
It's enough if you close the parentheses, or if there are none, if
it's followed by an unexpected character.

Beside, those problems of the Velocity syntax can be solved easily
(like, require () even if the directive has no parameters). So then I
read this as you are in favor of Velocity look-and-feel in general.

>> 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.
>
> In my opinion the issue is not with the closing of an empty
> directive, but with the end of directive syntax. The slash is short
> (1 character) but cryptic, it is not clear it means "end". My
> suggestion is to introduce an alternative syntax. Maybe:
>
> [@foo @end]
> [@foo]
> [@end]
>
> Equivalent to [@foo][/@]
>
> (May need to use #end instead of @end because the latter is valid
> directive name AFAIK so it wouldn't be backward-compatible)

We don't really care about BC in this discussion. The problem is
rather that [@foo @end] is awfully verbose, also [#foo #end]. How
about this:

  [#foo :]
    ...
  [#end]

and if you don't have nested content

  [#foo]

So the colon makes it obvious that we have started the nested content
and so there's a matching @end somewhere. You can also extend the
concept with:

  [#foo :]
    ...
  [#end-foo]

so that optionally, you can tell what directive are you closing.

But my problem is that while "end" is self-explanatory, it's too
verbose. That verboseness is OK for a Velocity-ish syntax, because
that don't have the [...]-s to help separating tags for the static
text. But here... it's "[@end" is too much IMO. Anyway, what I was
originally thinking about is:

  [#foo {]
    ...
  [}]

  or [} #foo], optionally.

and

  [#foo]

Quite obvious. I was happy with the idea, until I tried it in real
templates, and there I found it looks kind of noisy, because the {}-s
and [] looks to similar. That's maybe nit-picking, but... I have found
that despite it's *weird* and has steeper "learning curve", this looks
better after you get used to it:

  [#foo :]
    ...
  [#.]

  or [#. foo], optionally.

Yeah, takes time to get used to it. But then it applies two visual
tricks:

a) First, it lets your brain scan for "[#"-s, because even end-tags are
   start with "[#". So "[#" means "a tag starts here" and that tag is
   either "foo" or "." (means "end", like in "the end of a sentence").

b) Secondly, ":" and "." looks differently than "[" and "]"... so it
  doesn't add to the [{[]}[()(({[]([()])}))]] feeling.

>> 
>> - 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...)
>
> I like using "=" instead of "==". But for named arguments, you
> could replace x = a with x: a if you don't care about being
> SGML-like. It would be nice in fact.

I also happen to prefer ":":

- Its white-spacing is les verbose. Compare:

    x: 1, y: 2

  VS

    x = 1, y = 2

- Groovy uses it... JSON too, kind of. So it's more familiar in the
  Java/Web world. Familiarity is something I easily give up for other
  advantages, yet it's a nice plus when you can have it.

- Minor thing: It makes hunting down assignments easier, as only those
  use "=" then. It's maybe just me, but if often wind myself hunting
  for where a certain variable is assigned (in real programs at
  least...). Also, by introducing output parameters which use `=`, the
  assignment syntax need not be exceptional anymore.

But it also have some problems:

- Most certainly you can't have `exp ? exp : exp` due arising to
  ambiguities. However I hate the ternary op anyway... it takes both
  ":" and "?" away. To very useful and cute characters.

- You can't have ":" as name-space separator (like in XML). You can
  have dot of course, but... other topic but that has some
  disadvantages.

> -- Denis.
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> FreeMarker-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-devel
>

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev