Hi,
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..
I wanted the indent to be kept :) so the following would have been better
{eat-WS}#foreach( $d in $row.data ){eat-WS}
{eat-WS}#text( " <td>$d</td>" ){eat-WS}
{eat-WS}#end{eat-WS}
But as you mentioned, an additional newline is required :I
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>
not very pretty for structured input, I don't like the #**# to be at
the beginnng of the line. It would be OK if it where allowed directly
before the #if. Also again the extra empty line :I
So my proposal states not to gobble the whitespace around
(Directive|Schmoo)+ which avoids the #**# and the empty line...
Only gobble when WhiteSpace(Directive|Comment|Schmoo){1,1}WhiteSpace
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}
only a tick better than the first example ;)
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.
Yes, I've thought about the parser consequences for my proposed solution.
One idea I had is to make an AST-postprocessor to strip whitespaces
from text nodes post-parsing. This would not require changing the
velocity parser! But would have a small performacne impact.
The real solution is to keep the parser from creating the whitespace
nodes until the directives|text nodes in a line was created. If something
other than one and only one directive was on the same line, then the
parser creates the whitespace nodes before and after the normal line
content. I've not written any parser yet, but can imagine its not that
easy to do this.
With #pragma-selectable whitespace handling, some of these awkward
solutions might be avoided by explicitly specifying preferred handling
on a block-by-block basis.
Yup!
Side-note: I'm glad you like the name.. for 2 days, it was named after
you :-)
The initial BNF notation to my proposal was from Daniel Dekany in
http://marc.theaimsgroup.com/?l=velocity-user&m=101847719412093&w=2
This thread "Whitespace, redux" from 2002-04-10 has the full story
on the whitespace gobbling and some dicussed soltions/impacts, but
no conclusion (other than the proposed BNF).
An enhanced BNF, which considers VTL-comments is in:
http://marc.theaimsgroup.com/?l=velocity-user&m=101902732218948&w=2
DirectiveLine ::= LineEnd TabsAndSpaces? Markup TabsAndSpaces? LineEnd
TabsAndSpaces ::= (#x20 | #x09)+
LineEnd ::= StartOfStream | ((#x0D #x0A) | #x0D | #x0A) | EndOfStream
Markup ::= Directive | ## | Multi-line-comment
Multi-line-comment ::= (#**? ((#x0D #x0A) | #x0D | #x0A) *?*#)
[snip]
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.
Side note - #local is already reserved for a directive from Geir,
which lists a set of context variables which then are removed/restored
after the corresponding #end.
Maybe you could use another name like #use( ... ) ?
Both approaches for seem OK to me. Your solution is a bit simpler
because it avoids the (indented)block with an #end. But this is at
the same time its drawback, since you cannot control until where
the context pollution lasts within the same template. OTOH, this
drawback is of little importance, since the scope is limited to
one file on which the author has control.
- michael dykman
Greetings,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
