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

Friday, June 10, 2011, 1:28:55 PM, Daniel Henrique Alves Lima wrote:

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

So there are two things you have spared here:

- The $ before variable names. That's just horrible... even PHP has
  this. I'm not against such prefixes, as far as the most commonly
  used variables don't need them... And in a template that's variables
  from the data-model. In Velocity you need that $ before all of them.
  I suppose the idea was that it will look consistently with
  interpolations in static text, like $foo. (Which is already weird,
  because how am I supposed to insert an expression like ${foo + 1}
  then? ${$foo + 1}?)

- The parentheses... It's always a nice to remove them. However
  there's the C/Java/JavaScript tradition that requires them. Putting
  that aside, they are, coincidently, useful as separators in template
  languages:

    static#foo(1, 2)static

  VS

    static#foo 1, 2static

  The last obviosly doesn't work, so you have to introduce hack like:

    static#{foo 1, 2}static

  or maybe (not Velocoty-like):

    static#foo 1, 2;static

  but that's even harder to read. So I tried to get rid of the
  parentheses of method calls, but unless you have something like [#
  ... ] to delimit tags, I have never found it a good compromise.
  (Maybe I should try harder?)

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

Well, I have already chosen that same syntax as ideal for a template
language expression language. So I don't think it's bad... and it
looks nicely paired with named-parameters if those are using ":"
instead of "=" (and my choice is ":").

> 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]. (...)'

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