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

How do function calls inside of [.#] statements look?  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()}) ] ...  [#.]

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() }

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

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