[cc-ing vel dev]
Good list! Rest inline, mostly about parser issues that I am currently
juggling :
Christoph Reck wrote:
>
[snip]
>
> * Variables starting with a "_" underscore are not converted
> - should be allowed and added to the VL grammar.
That was a decision made a while ago. It's easy to fix if enough people
think it's a good idea. It would make our identifiers conform a little
better to the java spec. (Can we please get rid of the '-' as an
acceptable identifier character? How many people are going to regularly
use 'working-dogs' as a reference, jon? :)
> * Template error messages are emitted without stating the filename
> and wrong line numbers when using #parse.
> + In general template error messages are not very helpfull. I will
> try to provide patches when I get to it.
Yes, that's a whole bit I was meaning to get to.
> * A #set with a following comment causes a NPE, e.g:
> #set $color = "0x8080FF" ## light blue
Yes, currently the #set is standalone to help keep expression parsing
reasonable, but this example should be doable. On the same theme, how
do people feel about changing to #set( expression ) ? It will then
conform to our directive syntax #<directive>( optional arg ) and be
easier to put in-line in template code. So you can do things like
#set($foo = $bar + 2) + 3 bears...
w/o any muss or fuss. If people like this ( I do - its different but
useful), we can put the new one in and try to deprecate the existing
#set.
> * A file ending in a ## without an EOL emits a TokenMgrError.
My bad.
> * A #set without an "=" emits a NPE instead of an apropiate
> error message.
We can fix that in the parser or on the set code.
> [snip]
> * Whitespaces around standalone #if, #else, #end are preserved,
> it should be possible to handle them like a #set
> - Note that this would also make the VSL templates much more
> readable!
> ---
> #set $bar = true
> #if ($foo)
> \$foo=>$foo
> #else $foo undefined
> #if ($bar)
> \$bar=>$bar
> #else
> $bar undefined
> #end
> #end
> ---
> should emit
> ---
> $foo undefined
> $bar=>true
> ---
> where the first else is not standalone, therefore whitespaces
> are untouched, all other directives (even the indented ones)
> emit nothing (not even a EOL).
It does emit that, except for the two spaces before $bar=>true because
you have the #if indented.
The current behavior was a conscious decision, not an accident, and was
presented to the group with both an announcement as well as examples in
the testbed. The point is to balance between readable templates and
controllable output. It has been argued that whitespace should be
collapsed on the LHS of a standalone directive. Currently, whitespace
is collapsed on the RHS.
So directives don't emit the EOL, but they will produce the whitespace
on the left.
I'll take a whack at fixing that.
I had some example of where one would want this, but I forget now :) We
always have to make sure that all outputs are supported w/o excessive
contortions on the part of the template writer (in my opinion.)
>
> * Pluggable directives should contain a flag on the interface that
> states if whitespaces should be removed when these are standalone.
> A #parse should not touch whitespaches, whereas a #include should
> in my opinion work, e.g.:
> #set $data.Response.setHeader("content-type", "image/gif")
> #set $dummy = $data.getOut()
> #include ("/images/logo.gif")
That is incompatible with your previous argument, I think. (I assume
that you mean not the action of the PD, but rather the whitespaces pre
or post the #<dir>() syntactical element.)
I don't agree : I think that they all directives should behave the same
WRT LHS and RHS whitespace/newline gobbling. Lets keep things simple.
You can achieve the above my simply removing what I interpret are two
spaces before the include. So.
#set $data.Response.setHeader("content-type", "image/gif")
#set $dummy = $data.getOut()
#include ("/images/logo.gif")
should give you the correct output
I will be back friday afternoon to dig into this pile! (Thanksgiving
holiday here...)
Happy Thanksgiving.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
