velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <>
Subject Re[2]: Whitespace, redux
Date Thu, 11 Apr 2002 10:34:06 GMT
Thursday, April 11, 2002, 10:31:58 AM, Christoph Reck wrote:

> +0 to your rule in a) which contains the BNF to something 
>    *very* similar to what I proposed. 

> +1 If you leave the (WSSchomo? Directive)* out of it. 
>    I see the requirement that if you place multiple directives 
>    in one line, you are embedding something in your text.

That should be (Schomo? Directive)* anyway, I have overlooked it. So
in the example below do you feel that we should not gobble the
whitespace? Maybe. I can accept either gobble or not to gobble it.

#foreach($x in $foo)
  #if($x < 3)123#end

>    The whitespaces around a directive should only be gobbled
>    when it has been placed standalone in a line.
>    Geir, for character stream users, they could just put
>    a #**# upfront any directive to inhibit gobbling.
> Porposal Update: 
> If a line is looks like this:
>   DirectiveLine ::= LineEnd TabsAndSpaces? Directive TabsAndSpaces? LineEnd
>   TabsAndSpaces ::= (#x20 | #x09)+
>   LineEnd       ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream

Ops... ture I forgot the first LineEnd and the StartOfStream. :-/

> then the first "TabsAndSpaces?" and the closing "TabsAndSpaces? LineEnd" 
> should be gobbled. (Note that it supports multiline directives, that is 
> why "DirectiveLine" is not simply "Line".) If you whant the first 
> "LineEnd" to be gobbled prepend a ## before it (it is part of the
> previous line!).

OK. The updated a) is better.

> Daniel, could you live with this simplification?
> Note that the #echo directive you propose can be easily achieved 
> with a macro: #macro(echo $text)$text#end

No, I disagree here. The problem is that VTL is a language for
generating text based on templates as we know. If a "text template
language" can't output any text without your custom objects in the
context, then it has serious problems in it's core. This is something
like if Fortran doesn't support multiplication operator, because you
can implement it with your own function. Some of disadvantages of
custom solutions are: your code is less protable (copy-pasteable), the
reader of your code must know your custom components, and last not
least Velocity users have to reivent the wheel again and again. So I
say that you can live without a built-in #echo like macro, but
Velocoty will be more complete and better with it.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message