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

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
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...)

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Cervenak Ahern
Hi Daniel,

Still nicer than JSP though ... :)  What follows is a bit of a stream of consciousnesses  but...

I guess thought-wise I'd take one of two approaches - make it more SGML friendly and maybe end up with GXP or align it to work more like a programming language.

I'd prefer the latter option (and here is where I'd have to sketch it out on paper and get back to you).  Syntax wise I'd probably shoot for something LISP like? 

[#if {condition} [
   ...  
]]

And for a directive:

[@my-directive [= a b] [= x y] {arg} [

]]

I am certain this syntax is broken in many trivial examples.  One nice feature though, is that nested statements look good (if you like lots of brackets):

[@if [@directive {arg}, [@directive2], {arg}] [

]]

Just a crazy thought if you could fix the broken handling of that text block...

-Mike

On Tue, Jun 7, 2011 at 6:46 PM, Daniel Dekany <[hidden email]> 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...)

--
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
[hidden email]
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Daniel Dekany
Thursday, June 9, 2011, 10:41:04 PM, Daniel Henrique Alves Lima wrote:

> Hi Daniel.
>
> I forgot to answer this thread...
>
> A little context:
> Well, I've worked with JSP (and prior template engines) for a
> while. A few years ago I started working at a company in which the
> "web masters, novice PHP programmers who wrote the presentation
> layer of our application JEE, were accustomed to using Velocity. At
> that time I already knew Velocity because I had written some tools
> for source code generation. Unfortunately, for some reason (?), I
> did not like to use Velocity to produce (X)HTML. After some Googling, I found FreeMarker.
>
> A cool feature (or side effect of syntax) of Velocity and
> FreeMarker was to write a vm. or. ftl template, rename it to .html
> and "see" the result in a browser, without using any kind of
> backend. That was very helpful when I was writing templates for HTML
> emails. Off course, it won't work for any case.
>
>
> One lesson I learned from Groovy (and also from FreeMarker): Make a
> terse syntax. Keep the template readable by humans. Even using code
> completion, I really hate to write <abc-def:xyz
> a="${q.getAbc().toString()}" b="true"> when I can write <xyz a=q.abc b=true>. I also hate XML
> One lesson I learned from somewhere else: Make things easy for the IDEs. Probably a contradiction

Agreed in these directions...

What's your take on the [.../] thing? I have seen you like to write
[#include "..." /] and like, that is, you like to put that "/" there
even if it's not strictly necessary. That also means that you know
what it would be like if it's required. How annoying is that for you?
I mean, would it be better if you don't have to enter any extra chars
if there's no nested content, instead you had to type two extra charts
when there is (two, because one in the start-tag, and another int the
end-tag).

Also, you have mentioned Velocity. Was its *syntax* better or worse?
First of all, the look and feel of it. Then, which features you hated
and which did you like (over FTL)? (Like, is the ability to write $foo
instead of ${foo} good or bad at the end?)

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Michael Cervenak Ahern
Thursday, June 9, 2011, 8:36:24 PM, Michael Cervenak Ahern wrote:

> Hi Daniel,
>
> Still nicer than JSP though ...    What follows is a bit of a stream of consciousnesses  but...
>
> I guess thought-wise I'd take one of two approaches - make it more
> SGML friendly and maybe end up with GXP or align it to work more like a programming language.
>
> I'd prefer the latter option

(Me too, BTW. Especially as I have always found SGML/XML horribly
verbose for anything but describing documents. Maybe even for that...
Anyway, due to its popularity, a Java-ish/Groovy-ish syntax is
certainly a good bet.)

> (and here is where I'd have to sketch
> it out on paper and get back to you).  Syntax wise I'd probably shoot for something LISP like?
>
> [#if {condition} [
>    ...  
> ]]
>
> And for a directive:
>
> [@my-directive [= a b] [= x y] {arg} [
>
> ]]

Out of curiosity, do you have LISP background? Personally, I like to
avoid all kind of parentheses ((), [], {}) nested into each-other,
especially the same kind of parentheses nested into each-other
([[][]]). They confuse my eyes... But in a template languages you
possibly can't avoid them for separating the static text from the
"tags". They are quite nice for that actually. But that's just a
reason to avoid them even more *inside* the tags. For me, that is. In
principle I should do some kind of survey to know what's easy to read
for people...

> I am certain this syntax is broken in many trivial examples.  One
> nice feature though, is that nested statements look good (if you like lots of brackets):
>
> [@if [@directive {arg}, [@directive2], {arg}] [
>
> ]]

That's one aspect of LISP that I embrace... unify all the
function-like concepts. FreeMarker has directives VS functions. Or
technically, macros VS functions VS methods VS TemlpateDirectoveModel
VS transforms... horrible historical baggage.

However, using the same call syntax both inside and outside the tags
turns out to be problematic. Technically it's possible, even nice. But
the syntax of the top-level function calls (or directive calls, tags,
whatever) is optimized visually to stand out in the middle of the
messy static text. That's why an outer [...] is good there; it
visually cuts out the dynamic part from the rest. But inside the tag,
for me at least, it doesn't work very well, because it makes harder to
see where the outer tag ends. I mean, if you want to see where tags
start and where the end, you just hunt for "["-s and then for the
closest "]" after it. But if there tend to be [...]-s inside and hence
"]"-s... I still manage to find the matching "]", but it's somehow
more exhausting, slower. But maybe it's just my brain.

<OT>You can guess from there that LISP syntax is not for me. For me,
it's like a strange game where the computer repeatedly proves that it
can match parentheses better than me. Not only that... it also forces
me to satisfy its fetish for properly paired parentheses. Really, I
don't see difference between the correct and the wrong version, so
only the compiler needs this... :) With other words, I have found that
if something is very much generalized, while it's theoretically
powerful, it becomes kind of monoton and hard to digest for the human
brain.<OT>

> Just a crazy thought if you could fix the broken handling of that text block...
>
> -Mike
>
> On Tue, Jun 7, 2011 at 6:46 PM, Daniel Dekany <[hidden email]> 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...)
>
> --
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Henrique Alves Lima
In reply to this post by Daniel Dekany
Hi Daniel.

Some quick answers below. I'll re-read to this email later and answer it
properly (I have the multitasking ability of a Windows 3.11 :-P).

Daniel Dekany wrote:

> Thursday, June 9, 2011, 10:41:04 PM, Daniel Henrique Alves Lima wrote:
>
>  
> Agreed in these directions...
>
> What's your take on the [.../] thing? I have seen you like to write
> [#include "..." /] and like, that is, you like to put that "/" there
> even if it's not strictly necessary. That also means that you know
> what it would be like if it's required. How annoying is that for you?
>  
It's automatic. But I'm a freak. I write <br /> even in a non-well
formed html :-)

> I mean, would it be better if you don't have to enter any extra chars
> if there's no nested content, instead you had to type two extra charts
> when there is (two, because one in the start-tag, and another int the
> end-tag).
>
> Also, you have mentioned Velocity. Was its *syntax* better or worse?
> First of all, the look and feel of it. Then, which features you hated
> and which did you like (over FTL)?
I'll take some time to answer this one. It was a loooooooooooooong time
ago (maybe 3 years?). I barely remember how Velocity looks like.
> (Like, is the ability to write $foo
> instead of ${foo} good or bad at the end?)
>
>  
I wrote some (many?) shell scripts. So I have some issues about $foo (I
prefer ${foo}). But as I've said before, I'm a freak. I write
%WINDOWS_ENV_VAR% :-)
If my memory is not failing $foo was specially annoying in Velocity. I'm
just trying to remember why...

My answers were mostly useless :-|

I'm not particularly comfortable with the syntax of JSP and GSP:

http://www.grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.2%20Groovy%20Server%20Pages

<img src="<g:createLinkTo dir="images" file="logo.jpg" />" />


But is there a better way of writing a call to a function using named parameters/args?


<img src="${createLinkTo(dir:'images', file:'logo.jpg')}" />





------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Henrique Alves Lima


Daniel Henrique Alves Lima wrote:

>
> My answers were mostly useless :-|
>
> I'm not particularly comfortable with the syntax of JSP and GSP:
>
> http://www.grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.2%20Groovy%20Server%20Pages
>
> <img src="<g:createLinkTo dir="images" file="logo.jpg" />" />
>
>
> But is there a better way of writing a call to a function using named parameters/args?
>
>
> <img src="${createLinkTo(dir:'images', file:'logo.jpg')}" />
>
>
>  

<img src="${createLinkTo dir:'images', file:'logo.jpg'}" />

<img src="${createLinkTo file:'images/logo.jpg'}" /> (it's not a syntax problem)


?

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
Friday, June 10, 2011, 1:34:17 AM, Daniel Henrique Alves Lima wrote:

>
>
> Daniel Henrique Alves Lima wrote:
>>
>> My answers were mostly useless :-|
>>
>> I'm not particularly comfortable with the syntax of JSP and GSP:
>>
>> http://www.grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.2%20Groovy%20Server%20Pages
>>
>> <img src="<g:createLinkTo dir="images" file="logo.jpg" />" />
>>
>>
>> But is there a better way of writing a call to a function using named parameters/args?
>>
>>
>> <img src="${createLinkTo(dir:'images', file:'logo.jpg')}" />
>>
>>
>>  
>
> <img src="${createLinkTo dir:'images', file:'logo.jpg'}" />
>
> <img src="${createLinkTo file:'images/logo.jpg'}" /> (it's not a syntax problem)
>
>
> ?

You mean parenthesisless calls? Those can look cute, but they have a
great potential to cause headaches for the language designer (or for
the user). Like, this:

  ${foo -1}

Does it mean `${foo(-1)}` or `${foo - 1}`? Or even is `${foo}` a
method call or just printing the value of foo? (Typical quick answer:
Let's check the runtime type of `foo`, and if it's a callable...
Right, and then I can write ${someList.size} instead of
${someList.size()} too, right? Because that's maybe a bit too bold.
Yes, Scala does that. Except Scala also have methods where you can't
omit the parentheses because they have side effects. Also Scala is
insanely type-safe, which helps in resolving ambiguities of this kind
(should I call it VS should I just use it as value). Also it assumes
the programmer spent a lot of time with learning Scala, rearranging
his brain. You can't expect that for a template language, so it should
try harder to remain Java-ish.)

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Henrique Alves Lima


Daniel Dekany wrote:

>>>  
>>>      
>> <img src="${createLinkTo dir:'images', file:'logo.jpg'}" />
>>
>> <img src="${createLinkTo file:'images/logo.jpg'}" /> (it's not a syntax problem)
>>
>>
>> ?
>>    
>
> You mean parenthesisless calls? Those can look cute, but they have a
> great potential to cause headaches for the language designer (or for
> the user). Like, this:
>
>   ${foo -1}
>
> Does it mean `${foo(-1)}` or `${foo - 1}`? Or even is `${foo}` a
> method call or just printing the value of foo? (Typical quick answer:
> Let's check the runtime type of `foo`, and if it's a callable...
>  

I agree. It should be unambiguous.

${foo: 1} is an option for a method call, but this can clash with a map
literal(?)


${foo} printing value
${foo:} method call?
${foo - 1} = foo - 1
${foo: -1} method call

But

${foo: [a: 12, b: 3]} // [a: 12, b: 3] is a map literal

${foo: param1: 12, param2: 13}

Is 'param1: 12' a function call or a named arg?



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

bredelet
In reply to this post by Daniel Dekany
> Friday, June 10, 2011, 1:34:17 AM, Daniel Henrique Alves Lima wrote:
>
>> Daniel Henrique Alves Lima wrote:
>>>
>>> My answers were mostly useless :-|
>>>
>>> I'm not particularly comfortable with the syntax of JSP and GSP:
>>>
>>> http://www.grails.org/doc/latest/guide/6.%20The%20Web%20Layer.html#6.2%20Groovy%20Server%20Pages
>>>
>>> <img src="<g:createLinkTo dir="images" file="logo.jpg" />" />
>>>
>>>
>>> But is there a better way of writing a call to a function using named parameters/args?
>>>
>>>
>>> <img src="${createLinkTo(dir:'images', file:'logo.jpg')}" />
>>>
>>>
>>>
>>
>> <img src="${createLinkTo dir:'images', file:'logo.jpg'}" />
>>
>> <img src="${createLinkTo file:'images/logo.jpg'}" /> (it's not a syntax problem)
>>
>>
>> ?
>
> You mean parenthesisless calls? Those can look cute, but they have a
> great potential to cause headaches for the language designer (or for
> the user). Like, this:
>
>  ${foo -1}

This is not a call with named arguments. I think ${foo age: -1} is fine, but without arg name you should use ${foo(-1)}.

Personally I don't mind the brackets around variables, ie. I don't have a preference for $bar over ${bar}. In fact syntax consistency helps spotting variables in the midst of text.

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.

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

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

-- 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Daniel Henrique Alves Lima
Friday, June 10, 2011, 2:46:27 AM, Daniel Henrique Alves Lima wrote:

>
>
> Daniel Dekany wrote:
>>>>  
>>>>      
>>> <img src="${createLinkTo dir:'images', file:'logo.jpg'}" />
>>>
>>> <img src="${createLinkTo file:'images/logo.jpg'}" /> (it's not a syntax problem)
>>>
>>>
>>> ?
>>>    
>>
>> You mean parenthesisless calls? Those can look cute, but they have a
>> great potential to cause headaches for the language designer (or for
>> the user). Like, this:
>>
>>   ${foo -1}
>>
>> Does it mean `${foo(-1)}` or `${foo - 1}`? Or even is `${foo}` a
>> method call or just printing the value of foo? (Typical quick answer:
>> Let's check the runtime type of `foo`, and if it's a callable...
>>  
>
> I agree. It should be unambiguous.
>
> ${foo: 1} is an option for a method call, but this can clash with a map
> literal(?)

It doesn't clash with that. The '${' and '}' belongs to the
interpolation, so the expression to evaluate is clearly:

  foo: 1

> ${foo} printing value
> ${foo:} method call?

In principle it is... (However it's kind of weird because a colon
visually indicates that something is coming after it, but there
nothing is coming.)

> ${foo - 1} = foo - 1
> ${foo: -1} method call

and

  ${foo - 1} = A FAQ :)

> But
>
> ${foo: [a: 12, b: 3]} // [a: 12, b: 3] is a map literal
>
> ${foo: param1: 12, param2: 13}
>
> Is 'param1: 12' a function call or a named arg?

No ambiguity there, it's a function call. However it's not consistent
with [@fooDirective 1], which is unfortunate. Unless that should be
[@fooDirective: 1] too, but that would be too noisy for a such common
case. And really, if you just want to insert the return value of a
function, why not just call it like [@foo 1]? That said, functions and
directives should be united. Then there's no need for the ${...}
trick. That's also something that not really possible in FreeMarker;
uniting these two concepts, because it has no true automatic escaping.
(But not a problem, we aren't necessary talking abut FM here... I just
want to see what people think.)

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by bredelet
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
> [hidden email]
> 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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Denis Bredelet

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

I am in favor of the Velocity *directive* look and feel in HTML or XML templates.

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

I really don't mind the verboseness here. Keep [/@] as a shortcut.

> 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 :]
>    ...
>  [#.]

Ok but if we use colon for named arguments it will clash. How about:

[#foo]
...
[#.]

[#foo.]

>
>  or [#. foo], optionally.

-- 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Michael Cervenak Ahern
In reply to this post by Daniel Dekany
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 <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Henrique Alves Lima
In reply to this post by bredelet
Denis Bredelet wrote:
>
> 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.
>  
>

Visually nicer? For some cases, I disagree.

http://velocity.apache.org/engine/releases/velocity-1.7/vtl-reference-guide.html

<li>#if( $foo == $bar)it's true!#{else}it's not!#end</li>


I have some horrible examples of Velocity (I just need to find them :-))
where the sentences were made unreadable just to avoid extra space or
line break.

  Some examples of redundant notation in Velocity:

    * Variable reference: #set( $monkey = $bill )
    * String literal: #set( $monkey.Friend = 'monica' )
    * Property reference: #set( $monkey.Blame = $whitehouse.Leak )
    * Method reference: #set( $monkey.Plan = $spindoctor.weave($web) )
    * Number literal: #set( $monkey.Number = 123 )
    * Range operator: #set( $monkey.Numbers = [1..3] )
    * Object list: #set( $monkey.Say = ["Not", $my, "fault"] )
    * Object map: #set( $monkey.Map = {"banana" : "good", "roast beef" :
      "bad"})

    I would prefer (I'm not considering if it is doable):

    * Variable reference: #set monkey = bill
    * String literal: #set monkey.friend = 'monica'
    * Property reference: #set monkey.blame = whitehouse.leak
    * Method reference: #set monkey.plan = spindoctor.weave(web)
    * Number literal: #set monkey.number = 123
    * Range operator: #set monkey.numbers = [1..3]
    * Object list: #set monkey.say = ["Not", my, "fault"]
    * Object map: #set monkey.map = {banana : "good", "roast beef" : "bad"}


    The last one is tricky. It's the Groovy approach for a Map literal,
but I agree it probably isn't a good idea in a Template language.

http://groovy.codehaus.org/Collections

'(...) Map keys are strings by default: [a:1] is equivalent to ["a":1].
But if you really want a variable to become the key, you have to wrap it
between parentheses: [(a):1]. (...)'


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Henrique Alves Lima
In reply to this post by Daniel Dekany


Daniel Dekany wrote:

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

How about

#foo [aaaaaaa
aaaaa#if condition [aaaaa
aaaa
]aaaa
]aaaa

Or perhaps as cryptic as Velocity (sometimes).



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Denis Bredelet
Friday, June 10, 2011, 12:28:35 PM, Denis Bredelet wrote:

>> Friday, June 10, 2011, 8:36:15 AM, Denis Bredelet wrote:
[snip]
> I really don't mind the verboseness here. Keep [/@] as a shortcut.

I like to avoid choice in syntax if it doesn't bring much... Like
here, some people will use @end, some will use /@, and the result is a
mess. Also, new users will have to realize that the two means the
same. So then I rather just force everybody to use /@.

BTW, to prevent misunderstandings, I would like to emphasize that we
aren't (necessarily) talking about FreeMarker here. It's just brain
storming... I don't promise that any of these will make into a
template language, let alone into FreeMarker.

>> 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 :]
>>    ...
>>  [#.]
>
> Ok but if we use colon for named arguments it will clash.

Technically it doesn't, no problems there. Visually, a bit it does,
although ":]" which is always at the end of the tag anyway (and you
are supposed to see easily where a tag starts and ends) is easy to
spot and comprehend. For me at least.

> How about:
>
> [#foo]
> ...
> [#.]
>
> [#foo.]

The goal was to get rid of the upside-down situation where tag of
directive calls without nested content needs an extra character, while
tags that open nested content doesn't. (But maybe that goal itself is
mistaken.) So now we are back where we come from, except you are
basically that "." looks better than "/". (To be exact you also have
[#.] instead of [.#], which is a further difference from SGML's
approach.) Unless "." looks sooo much better than "/", and I doubt
that, I don't think it's a good tradeoff. If you keep the SGML-ish
logic (I mean that tags by default open a nested content), you might
as well keep "/", because however ugly it is, people are familiar with
it from HTML.

>>
>>  or [#. foo], optionally.
>
> -- Denis.

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Daniel Henrique Alves Lima
Friday, June 10, 2011, 6:16:32 AM, Brian Pontarelli wrote:

> Just require parens for method calls. That simplifies it and keeps
> in java-ish. Everything else is an operator.

Yeah. So as I said, I think that's how it should be (require
parentheses), except on the same time, functions and directives (and
methods!) should be unified, i.e., there should be only functions.
Then, if you have a tag-ish syntax and an interpolation syntax anyway,
if you just want to call a function or method you can use the tag
syntax, otherwise the Java-ish syntax. That's I believe is the right
track (and it calls for serious changes compared to FreeMarker).

BTW, I also tried using exactly the same syntax for tags and
expressions inside them... Easy, ignoring some details it's like
WebMacro. But too often it didn't looked well mixed with static text.
Although for some tasks it was very handy. That's another dilemma...
no syntax is ideal for all templating tasks. Supporting multiple
syntaxes which are "compiled" to the same AST is possible, but causes
segmentation among users (and even developer tools), so maybe it's
better to "force" a middle-road syntax on everyone.

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Daniel Henrique Alves Lima
Friday, June 10, 2011, 1:49:13 PM, Daniel Henrique Alves Lima wrote:

[snip]

>>   [#foo :]
>>     ...
>>   [#.]
>>
>>   or [#. foo], optionally.
>>
>>  
>
> How about
>
> #foo [aaaaaaa
> aaaaa#if condition [aaaaa
> aaaa
> ]aaaa
> ]aaaa
>
> Or perhaps as cryptic as Velocity (sometimes).

You are marching towards the WebMacro-ish syntax here. My main problem
with them is that "]" (or "}", the more usual choice) isn't very much
visible in the middle of the static text. Where that's not a problem,
WebMacro-ish syntaxes rock though (and here see my comment regarding
multiple syntaxes). The fact that a mere "]" has special meaning also
complicates matters. In WebMacro (where it was "}", not "]") it did
cause headaches. That problem can be handled well if you do allow "]"
in static text as far as it has a "[" pair in static text, in which
case the parser understands that the "[" and "]" are just static text.
Of course it raises the need for vertical-flow-statements (my term for
it...) like:

  #vIf condition [
    [ <- static, not printed if condition is flase
      #vEndIf [
        static, always printed
      ]
    ] <- static, not printed if condition is flase
  ]

but those are handy even if you have no syntactical problems, so
that's not a problem in itself.

--
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-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Michael Cervenak Ahern
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 <[hidden email]> 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
>> [hidden email]
>> 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
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Dekany
In reply to this post by Denis Bredelet
Friday, June 10, 2011, 1:59:18 PM, Daniel Henrique Alves Lima wrote:

> Denis Bredelet wrote:
>>
>>
>> Ok but if we use colon for named arguments it will clash. How about:
>>
>> [#foo]
>> ...
>> [#.]
>>
>> [#foo.]
>>
>>  
>>
>
> It's visually nice IMHO. My problem with notations like those It's to
> discover what directive is being closed by [#.]. IDEs or text editors
> are helpful for {}, [], () or <abc></abc>. But an special editor (or
> plugin) will be necessary to "fold" notations like
>
> [#foo]
> ...
> [#.]

But as it was shown, optionally you can write:

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

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