velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dekany <ddek...@freemail.hu>
Subject Re: Whitespace, redux
Date Fri, 19 Apr 2002 15:05:30 GMT
Friday, April 19, 2002, 1:04:14 PM, Christoph Reck wrote:

> Daniel Dekany wrote:
>> 
[snip]
>> If you have something like this:
>> 
>> <UL>
>>   #incrementCounter()#li("Male")
>>   #incrementCounter()#li("Female")
>>   #incrementCounter()#li("Neither")
>> </UL>
>> 
>> then nobody will belive that it will indent. And if you have a
>> dedicated directive to indent, then would not be cleaner to say
>> instead of Directive+ that NonIndentedDirective+?
>
> Does it indent or not? My rule states it will. As far as I used
> to understand your rule it would not, but below you're expanding

With Directive+ it will indent if #incrementCounter() is a vm call,
but will not indent if #incrementCounter() is a directive. If
#incrementCounter() is a vm call, then it will indent with both
Directive and Directive+.

> your rule with a statement that it will indent - inconsistent 
> to your #sendSMS(...) example in previous mail.

I see may mistake was that I have used Velocity-like syntax there. So
again, those part with the sendSMS examples was about: What do people
want to gobble whitespace and what not (i.e. to be indented).

[snip]
> Wow! Is this really so?
> So then the AST-nodes for directives need a flag for the runtime 
> to decide if it gobbles or not. Then macros, include, parse, and 
> echo will be flagged to stop gobbling.

Ops! OK, now I see the big problem in our communication. In may
terminology vm calls are NOT directives. Perhaps in your EBNF
Directive matches to vm calls?

[snip]
>> > I mean: if "Directive+" greedingly gobbles whitespaces, how do you stop it?
>> > OK, an #echo(...) could explicetely be used.
>> > But look at my example above how I believe it could be handled when
>> > just "Directive" applies.

> I meant 
>   #echo("")#one()#or()#more() #directives() #end

Let say for now that vm-s are considered as directives. Both Direcive
and Direcive+ will stop whitespace (indent) gobbling here. No
difference.

> or
>   #echo("#one()#or()#more() #directives() #end") 

Let say for now that vm-s are considered as directives. Both Direcive
and Direcive+ will gobble the whitespace before the #echo here, and
neither will gobble the whitespace in the quoted thing. Again, no
difference.

>>
>> I don't understand what you mean. Neither line above will gobble
>> whitespace. Note that #foo above is a vm.
>> 
>> <html>
>>    #foo#include('xyz')
>>    #if($bar)#foo#end
>>    #if($bar)baaz#end
>> </html>
> (note: #foo() needs parenthesis otherwise its schmoo)
>
> If you state that macro calls should stop the "Directive+" gobbling, 
> then thats right. 
> No additional rule/statement needed to achieve this using plain "Directive".

But... no. When you use "Direcive" then you still should guess if that
1 directive or vm call should gobble whitespace or not. Your
argument is that you should not guess it, because the template writer
will put another "nop" vm call there, just to stop whitespace
gobbling! Don't you feel that it is very very awkward?

> Summary:
> If the "Directive+" for of the rule should work, we need to add a flag
> to directives that indicate gobbling desired (or a flag that indicates 
> it may emit something - which would stop the gobbling). If others agree 
> with this approach, I also can agree with your "Directive+" proposal.

No, I would really hate those flags. In my proposal vm calls was NOT
directives, so read the ENBF with Directive+ as such. BTW I have
changed my mind. What about that the only think that gobbles
whitespace is: #if, #else, #elsif, #end, #set, #foreach, #stop, #macro
and comments (note that I have omitted #include and #parse).
Everything else prevents whitespace gobbling in its line. So instead
of Directive+ I say WhiteSpaceGobbler+.


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


Mime
View raw message