On Wed, 2004-11-03 at 14:47, Christoph Reck wrote:
> > #pragma sounds like a lovely idea!! I wish I thought of that myself.
>
> cool!
#pragma is on the way.. all the properties with the 'veracity.runtime'
prefix (except debug and enablewarnings) will be available as pragmas.
The whitespace and directarrayaccess options are, strictly speaking,
compile time options... I'm probably going to rename the 'runtime'
infix on those while I'm at it, but they will remain as pragma.
for example, to control the property
veracity.runtime.relativeresolution. you would have the options of:
#pragma('relativeresolution') ## turns relative resolution on
#pragma('enable-relativeresolution') ## turns relative resolution on
#pragma('disable-relativeresolution') ## turns relative resolution off
As some of these pragmas need to be known during compile time, only the
single quoted string is acceptable as a double-quoted string requires
runtime evaluation.
> my small hope is that your anouncement gives a small push to move
> on with velocity... There is a list of wanted features, but where
> no concesus was yet reached... Many people = many opinions, the
> originators see it as work-for-me, and expect you to scratch-your-own-itch.
> When there are workaround and the lead expresses no favour to one
> proposal, no one takes the initiative - since it might not find
> its way into the core.
I'm all for healthy debate and friendly competition; although when I'm
developing, the benevolent dictatorship model gets things done. By and
large, that's why I decided to implement rather than suggest.
> >>I do not yet fully understand your "structured" whitespace handling
> >>scheme (the name is superb!). Specially the part around "block comments".
> >>How would you allow something like:
> >> ...
> >> <table>
> >> #call( $formatter.makeAlternator("rowcolor", "#c0c0c0", "#e0e0e0") )
> >> #foreach( $row in $table.rows )
> >> <tr color="$rowcolor" >
> >> #call( $rowcolor.alternate() )
> >> #foreach( $d in $row.data )<td>$d</td>#end
> >> </tr>
> >> #end
> >> </table>
> It is a simple macro to avoid any side effects of a method call (return
> value):
>
> #macro( call $foo )#if( $foo )#**##end#end
>
> The #**# in the if-body avoided a parser bug in velocity 1.2.
> Initially I had #macro( call $foo )#set( $dummy = $foo)#end which
> polluted the context.
>
>
That occured to me after I pressed 'send'. I am not aware of any edge
conditions in Veracity as-is which would make this necessary.
> How do I get all row data in one line? One solution is:
>
> {eat-WS}#foreach( $d in $row.data ){eat-WS}
> {eat-WS-indent}#text( <td>$d</td> ){eat-WS}
> {eat-WS}#end{eat-WS}
ahh... you want all the <td> one one line, I'm not clear if you are
trying to keep the initial indent or not..
If no indent:
<tr color="$rowcolor" >
{eat-WS}#foreach( $d in $row.data )<td>$d</td>#end{eat-WS}
</tr>
We need the extra empty line to give a newline at the end of the
#foreach. {eat-WS} at the end of line, takes the newline as well.
To keep the indent, the comment prevents the whitespace from being eaten
at the beginning of the #foreach
<tr color="$rowcolor" >
#**# #foreach( $d in $row.data )<td>$d</td>#end{eat-WS}
</tr>
> Another example is:
> #foreach( $d in $row.data )
> $d#if( $velocityCount < $row.size() ),#end
> #end
> should producte a vertical list of indented data, not gobbling the
> newline at the end.
> How would your structured handling perform here?
Structured would eat the whitespace after the #end
This would give the result you want:
{eat-WS}#foreach( $d in $row.data ){eat-WS}
$d#if( $velocityCount < $row.size() ),
{eat-WS}#end{eat-WS}
{eat-WS}#end{eat-WS}
Some of these solutions I'm proposing don't look very pretty using
structured whitespace.. I'm still open to suggestion on behaviour (it's
not 5 days old yet), although a strict interpretation of your suggestion
in the Wiki would be pretty awkward to implement in my present
scanner/parser model. The scanner has to make decision about leading
whitespace long before the end of the line has been seen. I'm still
thinking about it.
With #pragma-selectable whitespace handling, some of these awkward
solutions might be avoided by explicitly specifying preferred handling
on a block-by-block basis.
Side-note: I'm glad you like the name.. for 2 days, it was named after
you :-)
> I took the existing VelocityFormatter as an example:
> http://cvs.apache.org/viewcvs.cgi/jakarta-velocity/src/java/org/apache/velocity/app/tools/VelocityFormatter.java?rev=HEAD
>
> Your proposed pattern:
> #local( $rowcolor = $formatter.makeAlternator("#c0c0c0", "#e0e0e0") )
> is better and keeps the context clean if it was in a macro or
> parsed template (does it?).
Yes! Variables defined with #local in a macro or parsed template
disappear when the macro or template is done. Always-global assignment
was one of my biggest peeves.
- michael dykman
- [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
