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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
