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

Friday, June 10, 2011, 1:10:05 PM, Michael Cervenak Ahern wrote:

> How do function calls inside of [.#] statements look?

You can't call anything there, it's just the end-tag. It's like "}" in
Java, only it can optionally repeat the directive name from the
start-tag (like in HTML).

> I guess I can buy a lot of this, but it do you gain a something by
> pulling in the () function call suggestion earlier in the thread?
> The [.] is good for indicating a block, but if you just adopt
> pseudo-JavaScript style notation then...
>
> [# foo()]
> ..
> [#.]
>
> [#. foo()]
>
> With a non trivial case...
>
> [#. foo( {x: bar(), y: foobar(), z: a, b: 'c' } ) ]
>
> Or
>
> [# foo ( [ 1..bar({x: y, z: fb()}) ] ...  [#.]

*Lost* of parentheses ({}, [], ()) everywhere. People don't like it,
or at last I don't. Confuses my eyes. Surely there are those who could
get used even LISP... but that's a minority, I guess (and they will
never understand why everybody pesters them due to that syntax).

Like, if you say `[# foo(1, 2)]`, there the [ and ] has already made
clear where the parameter list ends. So you could just write
`[# foo 1, 2]`.

OR, you can say that anything between `[#` and `]` is in the
expression language syntax. By that you have also get rid of ${...}.
Like:

  Hello [# user ]!  <-- that's like ${user}

  [# if (hasMessages) { ]
    You have new messages.
  [# } ]

Or maybe it more familiar if I write it like this:

  Hello [% user %]!  <-- that's like ${user}

  [% if (hasMessages) { %]
    You have new messages.
  [% } %]

That's something I have considered. It very clean and obvious, but
kind of verbose.

> Inside of a ${} it works the same way:
>
> -- Func call
> ${ foo ( [1..bar({x: y, z: fb()} )] }
>
> -- output variable
> ${foobar}
>
> You could even collapse things further and eliminate the [#.FN()] notation in favor of just:
>
> [# func()]..[#.] 
> and
> ${ func() }

Isn't this the same as it was one message ago?

> Regards,
> -Mike
>
>
>
> On Fri, Jun 10, 2011 at 11:06 AM, Daniel Dekany <[email protected]> wrote:
> 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

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