You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Michael Dykman <mi...@dykman.org> on 2004/11/03 15:39:41 UTC
Re: Announcement: Veracity suggestions for enhancements
On Tue, 2004-11-02 at 05:27, Christoph Reck wrote:
> Hi,
>
> this sounds interesting. You have addressed many/most of the Velocity
> drawbacks. One additions would be allowing (optional) commas in macro
> calls, to be similar as method calls.
O yeah.. The syntactic ambiguity mentioned in the Syntax/Macros section
is precisely caused by the lack of commas.. Without double-checking my
grammar, I'm pretty sure that would be easy to implement. As an old C
hand, I find the comma-less invocation a little disconcerting.
> Your enhancements are mostly OK. But yet I would see the many configurable
> options via properties as a drawback, since taking a template or macro
> from one site to the other may choke due to different option settings.
The use of all the configurable properties was to be able to ship
something that cautious users could expect to act like Velocity and then
gradually experiment with enhanced features
>
> I would suggest to have inline pragma directives or something like the
> velocity-tools ToolboxManager to fine tune the scope of the settings
> (and allow third-party-macros and toolbox-templates to have their
> private settings?).
#pragma sounds like a lovely idea!! I wish I thought of that myself.
>
> It will be a bit hard to keep Veracity in sync with Velocity, since
> some features like maps and multi-line directives are coming soon.
time will tell. the structure of the actual code is pretty transparent
and, for the most part, adding features has not been a big hassle.
>
> 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>
> and have nicely formatted output with all data together but yet indented?
(note: I am kind-of newbie to this list, I haven't missed the #call
directive have I? I have just search vtl-reference-guide.html and the
change log.. don't see a thing.. neat idea though)
I think this _would_ give you what you want if I supported the #call
directive.. ({eat-WS} marks the whitespace that would disappear with
structured WS handling)
<table>
{eat-WS}#call( $formatter.makeAlternator("rowcolor", "#c0c0c0", "#e0e0e0") ){eat-WS}
{eat-WS}#foreach( $row in $table.rows ){eat-WS}
<tr color="$rowcolor" >
{eat-WS}#call( $rowcolor.alternate() ){eat-WS}
{eat-WS}#foreach( $d in $row.data ){eat-WS}
<td>$d</td>
{eat-WS}#end{eat-WS}
</tr>
{eat-WS}#end{eat-WS}
</table>
Still possible to do this using conventional factory methods and old-style
method invocation.
#local($rowcolor = $factory.makeAlternator("#c0c0c0", "#e0e0e0"))
...
<tr color="$rowcolor.alternate()" >
...
Could you please explain the expected behaviour of
$formatter.makeAlternator("rowcolor", "#c0c0c0", "#e0e0e0")
to me? Is '$formatter' a special factory with access to the runtime
variable space? I have an idea coming on...
Than you very much for the feedback.. expect some of these suggestions
to be implemented sooner than later.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Announcement: Veracity suggestions for enhancements
Posted by Michael Dykman <mi...@dykman.org>.
Hello again,
<snip>
> 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
>
by 'Shmoo', do you you mean a macro invocation (as opposed to a
definition)?
> > {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 ;)
>
agreed..
> >
> 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.
As I mentioned earlier: this proposal, while elegant in concept, might
be very awkward to implement given my structure, but I have an idea
forming which may or may not work out.
I'm considering a 'conditional-whitespace' node type with an array to
define the condition on a per-line basis. During actual output
rendering, we could decide then what to do..
For the moment, anyone actually _using_ Veracity in production setting
(which is just me, I'm pretty sure) should consider Structured behaviour
to be liable to change.
> >
> > 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!
>
> 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) *?*#)
>
Thanks, I'll give them a read before any further major whitespace
surgery.
> 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( ... ) ?
>
Interesting... #use is reserved in the back of my head to be employed in
the perl-sense of 'yank some utilities/libraries' , although #pragma
might cover this ground.. how about #lset(...), then re-implement
#local to be visible within the current directive block, or document if
not in a directive block?
> 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.
Bear in mind that #local/(proposed #lset) as it stands when used inside
a macro does not pollute outside the macro, which was the primary usage
I had in mind initially.. Outside of macros, the ability to stay
visible to the end of page while not polluting parents should be handy:
#if($array.length == 0)
#local($msg = "No results were found")
#elseif($array.length > $maxperpage)
#local($msg = "Do you want to see details on the first $maxperpage")
#else
#local($msg = "Do you want to see details on all $array.length?")
#end
<b>$msg</b>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
--
- michael dykman
- michael@dykman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Announcement: Veracity suggestions for enhancements
Posted by Christoph Reck <ap...@recks.org>.
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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Announcement: Veracity suggestions for enhancements
Posted by Michael Dykman <mi...@dykman.org>.
On Thu, 2004-11-04 at 08:13, Gonzalo Diethelm wrote:
> > 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
>
> One suggestion: make these stack-like:
>
> #pragma-push('relativeresolution', 'enable')
> #pragma-pop('relativeresolution')
>
> (with whatever syntax). This is incredibly useful.
Thank you for the suggestion.. I'm still puzzling out some of the
esoterica introduced by #pragma.. I'll keep this one in mind.
- michael dykman
- michael@dykman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Announcement: Veracity suggestions for enhancements
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> 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
One suggestion: make these stack-like:
#pragma-push('relativeresolution', 'enable')
#pragma-pop('relativeresolution')
(with whatever syntax). This is incredibly useful.
Regards,
--
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Announcement: Veracity suggestions for enhancements
Posted by Michael Dykman <mi...@dykman.org>.
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
- michael@dykman.org
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Announcement: Veracity suggestions for enhancements
Posted by Christoph Reck <ap...@recks.org>.
Hi again!
Michael Dykman wrote:
> On Tue, 2004-11-02 at 05:27, Christoph Reck wrote:
>
>>Hi,
>[snip]
>>I would suggest to have inline pragma directives or something like the
>>velocity-tools ToolboxManager to fine tune the scope of the settings
>>(and allow third-party-macros and toolbox-templates to have their
>>private settings?).
>
> #pragma sounds like a lovely idea!! I wish I thought of that myself.
cool!
>
>>It will be a bit hard to keep Veracity in sync with Velocity, since
>>some features like maps and multi-line directives are coming soon.
>
>
> time will tell. the structure of the actual code is pretty transparent
> and, for the most part, adding features has not been a big hassle.
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.
Will-Glass has done a great job in the past with many patches.
To my knowledge some still reside in Bugzilla.
Others have initiated contribution areas in the Wiki - for voting,
discussions, and macro contributions.
>
>>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>
>>and have nicely formatted output with all data together but yet indented?
>
> (note: I am kind-of newbie to this list, I haven't missed the #call
> directive have I? I have just search vtl-reference-guide.html and the
> change log.. don't see a thing.. neat idea though)
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.
>
> I think this _would_ give you what you want if I supported the #call
> directive.. ({eat-WS} marks the whitespace that would disappear with
> structured WS handling)
>
> <table>
> {eat-WS}#call( $formatter.makeAlternator("rowcolor", "#c0c0c0", "#e0e0e0") ){eat-WS}
> {eat-WS}#foreach( $row in $table.rows ){eat-WS}
> <tr color="$rowcolor" >
> {eat-WS}#call( $rowcolor.alternate() ){eat-WS}
> {eat-WS}#foreach( $d in $row.data ){eat-WS}
> <td>$d</td>
nope :I
here the data would appeach each on its own line.
This is just an example test-case.
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}
where the #text is a simple macro.
-> this would be a feasible solution with your structured whitepsace
handling solution.
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?
> {eat-WS}#end{eat-WS}
> </tr>
> {eat-WS}#end{eat-WS}
> </table>
The rest seems perfectly appropiate!
>
> Still possible to do this using conventional factory methods and old-style
> method invocation.
>
> #local($rowcolor = $factory.makeAlternator("#c0c0c0", "#e0e0e0"))
> ...
> <tr color="$rowcolor.alternate()" >
> ...
>
> Could you please explain the expected behaviour of
> $formatter.makeAlternator("rowcolor", "#c0c0c0", "#e0e0e0")
> to me? Is '$formatter' a special factory with access to the runtime
> variable space? I have an idea coming on...
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?).
>
>
> Than you very much for the feedback.. expect some of these suggestions
> to be implemented sooner than later.
Cheers,
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org