Re: What's the ideal syntax?

[Will Glass-Husain <wg...@forio.com>]

Hi Daniel,

Thanks for the interesting comments.

The $foo vs ${foo} issue doesn't seem that important to me.  There's some 
issues with Velocity syntax we struggle with -- escaping of directives is a 
little strange for example -- but in general I haven't found references to 
be that difficult.  Perhaps that's because I don't use a lot of literal '$' 
in HTML.

Plenty of other templating and web languages prove that <% %> style 
delimiters work fine.  PHP, ASP, JSP, Perl's Template Toolkit.  Jonathan's 
point in an earlier email that these type of delimiters often work better 
with IDE's is a good one.  (Though I disagree with the assumption that 
everyone uses or needs to use an IDE.)  However I've tried two different 
Eclipse plugins for Velocity and both seem to recognize directives fine (and 
do a decent job with references).

One thing I'd like to see in Velocity is support for nested block 
statements.  JSP's nested tag elements have always appealed to me.  For 
example, DisplayTag (http://displaytag.sourceforge.net) would be hard to 
implement with Velocity since it has a block tag for the table and nested 
tags specifying each column.

Having said all that it's likely in Velocity we'll continue forward in ways 
that are consistent with current syntax - once design choices are made it's 
hard to change them without alienating existing users.  But it's interesting 
to consider alternatives particularly for those creating or adopting 
different systems.

Best,
WILL

P.S.  Incidentally, #{else} is now legal syntax in the upcoming 1.5 release. 
I always hated #else#**#blah#end myself.


----- Original Message ----- 
From: "Daniel Dekany" <dd...@freemail.hu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, October 07, 2005 10:05 PM
Subject: What's the ideal syntax? Was: [ANN] Viento - WHY?


> Friday, October 7, 2005, 11:12:21 PM, Chad Meadows wrote:
>
>> I simply don't quite understand what seems to be a pushback to
>> acknowledging there is a community of people who do not like the syntax. 
>> I
>> have shown the syntax of velocity side by side with freemarker among 
>> those
>> who had never seen either.  Velocity was preferred.
> [snip]
>
> DISCLAIMER: This will NOT be a FreeMarker advertisement. Also, I do NOT
> like the FreeMarker syntax (but not because of it usage of cryptic
> delimiters... there other things historically bungled in it), although I
> surely prefer it over Velocity's.
>
> <meta-discussion>
> The unimportant thing what I want to say is that Jonathan  behaves
> roughly in this case because he becomes angry when he faces exactly the
> same case of, well, apparent lack of professional experience (read:
> ***IGNORANCE!!!***, just I don't wanted to say that :)) again and again
> and again... the syntax stuff. (Plus, he is pissed of on Jakarta people
> in general, so it's not the place where he will try to keep cool his
> blood when it wants to boil.)
> </meta-discussion>
>
>
> So, what "apparent lack of professional experience" do I refer to?
>
> One thing is that evaluating a template language primarily based on the
> first impression "look and feel" goodness of its syntax is, well... Even
> evaluation a template engine primarily based on it syntax is, well...
> (as far as the syntax is within the borders of sanity, that is). But let
> this alone now too.
>
> The other thing is, that unfortunately a syntax that look simple,
> especially one that look good for non-programmer person at the first
> glance, always have the dark sides, that are not apparent first. But
> later... later you will swallow them because you are already get used to
> the basic syntax... but the point is, it turns out that the syntax is
> not that good after all. Like, I agree that WebMacro-style syntax (like
> Velocity's) looks friendly at the fist glance, but unfortunately it
> turns out that this type of syntaxes has some problems, which eventually
> fade out the advantage of first-impression natural look (I will not deal
> with strictly VTL specific design mistakes and bugs, since those has
> trivial fixes):
>
> - To show it in VTL: #else#**#blah#end. I bet most non-programmer will
>  not figure out easily that they should use that #**#, and anyway it's
>  awkward. But it could be solved as #{else}blah. Still, then the syntax
>  has already lost from its minimalism. Because, there are two ways of
>  writing the same thing, and then wouldn't be simpler if there is only
>  one way, the way that's always safely works? Anyway, especially for
>  non-programmers, the delimiting issue is something more mystical than
>  for a programmer: "Hm.... I don't want space here... will #elseblah be
>  OK? (try) Sh*t... now what to do? (phone)" (Of course, it's the kind
>  of thing that the guy will not foresee when he falls in love with Vel.
>  at the first glance.) But, if you want, let's say it's a minor issue.
>
> - The $foo VS ${foo} thing. The same as with #else basically.
>  Complicates things... why not just one *safe* way (it's clean for
>  everybody where's the end of the expression), which is ${foo}. Instead
>  of two ways? Much simpler, the documentation will be sorter... Yes,
>  more typing, but I think it worth it in the case of template language.
>  But, again if you want, let's say it's a minor issue.
>
> - BTW as a side note, with $foo you can really use "complex"
>  expressions, like ${x + 1}. With ${...} it naturally works.
>
> - Again $foo VS ${foo}. You have high chance that something that meant to
>  be static text will be interpreted as a reference. Like $Id: ...$
>  Not a that minor issue... And yet another catch to remember.
>
> - And the most important for the last... how do you call a macro with
>  body (like <my:stuff>...</my:stuff> in JSP) with this syntax? I know,
>  Vel. doesn't support it anyway, except for some built-in directives,
>  but many template language will definitely want to (like JSP,
>  FreeMarker, Viento), for good reason IMO. Now I don't go into the
>  endless variations of solutions that I tried "on paper" and then
>  thrown away, because they had too many catches, or was too verbose, or
>  look far too alien. Can anybody show me a good solution with more-less
>  WebMacro (Velocity) style? (And don't forget to count with the text
>  editors, for which a syntax highlight should be possible.)
>
> I have rumbled a lot about template syntaxes in the past. I really tried
> to find out syntaxes that have a WebMacro (or Velocity) look-and-feel,
> or just otherwise natural look if you see what I mean. (Note that not
> supporting macros with body is not acceptable for me.) For my biggest
> regret, I have found that at the end of the day, the simplest and most
> reliable syntaxes, the best compromises, were are always those where
> there are strictly required delimiters at the left and right side of the
> directives, like <#...>, or [#...], or even <%...%>, also ${...}, or
> #{...}, etc, i.e. not the WebMacro look-and-feel stuff at all.
> Furthermore at least the left side delimiter should be something that
> doesn't clash with anything that can easily occur in the static text, so
> just [...] is not enough, you need some additional strange character
> after the "[" (and even before the "]" if you want really text-editor
> friendly language). Yes, these syntaxes look alien at the first glance,
> but I believe that after that initial emotional shock (%-/ "Whaaaat?"),
> you will be better with them. They free of ambiguities (no cookbook
> tricks needed), they are safer (less chance of accidental clashes),
> while their rules can still remain damn simple. And, that they are
> necessary more verbose than WebMacro style syntaxes is a myth... they
> are just little bit more verbose, no important difference in that.
>
> -- 
> Best regards,
> Daniel Dekany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org