You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Bert van Brakel <be...@tuaworks.co.nz> on 2003/10/29 07:36:26 UTC
Wish for a new directive and a modified macro definition
Hi Guys.
I like the idea of macros, however I would like to extend it some more.
I would like to be able to set named variables for a macro. I will call
them 'widgets'.
A widget definition would be similiar to a macro with some changes:
#widget( mywidget foo=$first bar=$second )
<h1>Hello $first and $second</h1>
#end
From my template I would call:
#set( $bob = "mary")
#widget( mywidget foo=$bob bar="alice" )
Which would produce:
<h1>Hello mary and alice</h1>
A slightly larger example could be:
as a widget call:
#widget( hobbiesTable title="Hobbies Table"
onMouseOver="Javascript:jump" linker="$linker" items="${hobbies}"
bgcolor="blue" footer="Table 3")
or as a macro call:
#macro( hobbiesTable "Hobbies Table" ${hobbies} "Javascript:jump"
$linker "blue" "Table 3")
The widget one is obviously much longer but also a lot clearer. It is
easier to see what is set without having to lookup the macro and count
the variable position. Order of the variables isn't important, and if
more are added they can be put anywhere in the widget definition without
affecting templates which already use it.
variables which aren't set are null.
So spec is:
#widget( [widget-name [var-name=[local-var-name]]* ] )
#end
I really don't have a clue how the internals of velocity work so I don't
know how hard it is to implement, but it's something that I've been
wanting for quite some time and haven't found any other way to do. To my
mind it doesn't break velocity prinicipals, and from the templates
designers point of view is very easy to use.
Thanks for listening.
-Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Bert van Brakel <be...@tuaworks.co.nz>.
Christoph.Reck@dlr.de wrote:
> Here come some enlightening thoughts on this subject ;)
>
> One of the prime design drive of velocity was to keep it simple.
>
> Your wish seems ok, maybe with some polishing... (see embedded
> comment ) but would move velocity into a *real* scripting area.
> Your proposal would be understandable by programmers, but find
> little understanding by template designers.
<snip>
>
>
> #macro( mywidget $map )
> <h1>Hello $map.foo and $map.bar</h1>
> #end
>
> From my template I would call:
>
> #set( $bob = "mary")
> #mywidget( { foo:$bob, bar:"alice" } )
<snip>
> Geir, is the map syntax allowed in a macro call parameter?
> - otherwise you will need to define a reference first:
> #set( $params = { foo:$bob, bar:"alice" } )
> #mywidget( $params )
I'm not sure if I agree with you that template designers won't
understand it. When they call html they use: <some tag att1="value1"
att2="val2" /> etc.. which looks similiar to what I am proposing so
should be very familiar.
The call:
#mywidget( { foo:$bob, bar:"alice" } )
is not as simple as it could be. Why the '{' and '}' ? I know the
technical reason but from a designers point of view it doesn't convey
any extra info. Why not have:
#mywidget( foo:$bob, bar:"alice" )
and back again to:
#mywidget( foo=$bob bar="alice" )
which looks more like html tags.
You may have a point though on the macro definition side of it as it
does look a bit confusing, so maybe a better approach could be dreamed
up there.
That said the map pattern is more workable than the current position
based pattern and if it's already implemented then that is good and one
must take what one is given:)
However see my comment further down regarding local variable names...
> Cheers,
> Christoph
<snip>
>>
>>
>> #widget( mywidget foo=$first bar=$second )
>> <h1>Hello $first and $second</h1>
>> #end
>
>
> Some polishing...
> Why are you proposing to map foo to first? It makes no sense
> to use two different names to refer to the same value: why
> does the caller need to use foo= and the widget body $first?
>
I thought you may ask :)
The reason is that I want to be able to change the local variable names
of the macro without affecting how its called. ie trying to decouple the
implementation from the caller. I'm wanting to make a library of widgets
I can call (spread among various files and assembled into a macro
library art runtime) and don't want changes in the macro, due to say an
upgrade or different look, from affecting the call in templates. As long
as the macro writer does the mapping right they are free to write the
macro however they want, and add any extra args.
The downside ofcourse is that default values aren't built in as nicely
and would have to be done manually (by testing for null and setting it).
Also by stating the input variables at the top of the macro you won't
have to search through the macro to see which variables goes where,
though one could just provide good comments at the top of the macro.
Consider it more of a java object approach. You know what goes in, and
what comes out but you don't really care (much) about what happens inside.
Cheers,
-Bert
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Ch...@dlr.de.
Geir Magnusson Jr. wrote:
> I wasn't sure - I tested it and it didn't work. Fixed - you can now do :
>
> #foo( { "a" : $thing, "b" : $otherthing } )
>
> Thanks for making me think about it.
>
> geir
Cool!
I guessed from history that this might not have Worked ;D
To your other mail, I see a light at the end of the tunnel
- I mean looking back in the mail archive ;) This has been
requested before...
make that:
> Another options, should we want to support this, is keep it the same :
>
> #macro( thingy $foo $bar )
#macro( thingy $foo $bar="world" )
^^^^^^^^ allow defaults
> Hi $foo $bar!
> #end
>
> and only change the *calling* approach :
>
> #thingy( foo=$myvar )
#thingy( $foo="alice" )
^ use as everywhere else in velocity syntax!
To output
Hi alice world!
OTOH, with the map approach I beleive we got a good enough pattern
for velocity to KISS:
#macro( default $value $default )#if($value)$value#else$default#end#end
#macro( mywidget $map )
Hi #default($map.foo, "big") #default($map.bar, "world")!
#end
And call it by:
#mywidget( { "foo":"alice" } )
TBD:
+ Does someone see the map use case and the explicit defaults hard
to understand/explain for template designers?
+ Is the explicit assignment of defaults to macro parameters
desireable?
+ How will this play together with the mentioned macro overloading
(with different parameter counts)?
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Mike Kienenberger <mk...@alaska.net>.
> Mike Kienenberger wrote:
> >#mymacro ( "foo":"alice" ) & #mymacro( "alice" )
Bert van Brakel <be...@tuaworks.co.nz> wrote:
> And if you're at it why not
>
> #mymacro ( foo:"alice" ) & #mymacro( "alice" )
>
> or
>
> #mymacro ( foo="alice" ) & #mymacro( "alice" )
>
> The extra quotes are superfluous in terms of conveying information.
> Html designers understand '=' signs and would be clearer then ':'
Yes, I was originally commenting on the map construction syntax, but I
definitely agree that
#mymacro ( foo="alice" ) & #mymacro( "alice" )
is the clearest/most intuitive/most popular solution, especially for html
designers.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Bert van Brakel <be...@tuaworks.co.nz>.
Mike Kienenberger wrote:
<snip>
>
>Named parameters are easier to understand than position parameters.
>My guess is that the largest non-programmer user group right now is html
>designers.
>Html uses named parameters.
>
>Also, I think would would be better done by adding this to #macro rather
>than creating #widget -- KISS
>
>
>
agreed
>>+ Does someone see the map use case and the explicit defaults hard
>> to understand/explain for template designers?
>>
>>
>
>Having two call patterns with different syntax is always harder than one
>syntax and call pattern.
>
>#widget( "foo":"alice" ) & #mymacro( "alice" )
>
>vs
>
>#mymacro( { "foo":"alice" } ) & #mymacro( "alice" )
>
>vs
>
>#mymacro ( "foo":"alice" ) & #mymacro( "alice" )
>
>
And if you're at it why not
#mymacro ( foo:"alice" ) & #mymacro( "alice" )
or
#mymacro ( foo="alice" ) & #mymacro( "alice" )
The extra quotes are superfluous in terms of conveying information.
Html designers understand '=' signs and would be clearer then ':'
>The Velocity motto appears to be "keep the syntax as simple as possible",
>and adding named parameters to #macro works cleaner in this regard than the
>map syntax.
>
>
>
>
>>+ Is the explicit assignment of defaults to macro parameters desireable?
>>
>>
>
>I have macros where this would be very desirable.
>
>
>
Yes though it could be fudged currently
>>+ How will this play together with the mentioned macro overloading (with
>>
>>
>different parameter counts)?
>
>My guess: If you have named parameters with defaults, you can get by without
>macro overloading and variable argument counts.
>It will depend what creative uses people have come up with for macros.
>
>-Mike
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Mike Kienenberger <mk...@alaska.net>.
"Geir Magnusson Jr." <ge...@optonline.net> wrote:
> > Your wish seems ok, maybe with some polishing... (see embedded
> > comment ) but would move velocity into a *real* scripting area.
> > Your proposal would be understandable by programmers, but find
> > little understanding by template designers.
>
> I think this is true.
Named parameters are easier to understand than position parameters.
My guess is that the largest non-programmer user group right now is html
designers.
Html uses named parameters.
Also, I think would would be better done by adding this to #macro rather
than creating #widget -- KISS
> + Does someone see the map use case and the explicit defaults hard
> to understand/explain for template designers?
Having two call patterns with different syntax is always harder than one
syntax and call pattern.
#widget( "foo":"alice" ) & #mymacro( "alice" )
vs
#mymacro( { "foo":"alice" } ) & #mymacro( "alice" )
vs
#mymacro ( "foo":"alice" ) & #mymacro( "alice" )
The Velocity motto appears to be "keep the syntax as simple as possible",
and adding named parameters to #macro works cleaner in this regard than the
map syntax.
> + Is the explicit assignment of defaults to macro parameters desireable?
I have macros where this would be very desirable.
> + How will this play together with the mentioned macro overloading (with
different parameter counts)?
My guess: If you have named parameters with defaults, you can get by without
macro overloading and variable argument counts.
It will depend what creative uses people have come up with for macros.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, October 29, 2003, at 04:30 AM, Christoph.Reck@dlr.de
wrote:
> Here come some enlightening thoughts on this subject ;)
>
> One of the prime design drive of velocity was to keep it simple.
>
> Your wish seems ok, maybe with some polishing... (see embedded
> comment ) but would move velocity into a *real* scripting area.
> Your proposal would be understandable by programmers, but find
> little understanding by template designers.
I think this is true.
>
> The same programmers would also manage to work with arrays and
> maps (great new feature in the velocity HEAD version!).
>
> So keeping it simple, the new velocity should allow to code your
> wish using something like:
>
> #macro( mywidget $map )
> <h1>Hello $map.foo and $map.bar</h1>
> #end
>
> From my template I would call:
>
> #set( $bob = "mary")
> #mywidget( { foo:$bob, bar:"alice" } )
>
> Which would produce the same output you requested!
>
> And the greatest thing is that this already works!
> - I mean in theory; I havn't tested it yet :D
> Geir, is the map syntax allowed in a macro call parameter?
I wasn't sure - I tested it and it didn't work. Fixed - you can now do
:
#foo( { "a" : $thing, "b" : $otherthing } )
Thanks for making me think about it.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Ch...@dlr.de.
Here come some enlightening thoughts on this subject ;)
One of the prime design drive of velocity was to keep it simple.
Your wish seems ok, maybe with some polishing... (see embedded
comment ) but would move velocity into a *real* scripting area.
Your proposal would be understandable by programmers, but find
little understanding by template designers.
The same programmers would also manage to work with arrays and
maps (great new feature in the velocity HEAD version!).
So keeping it simple, the new velocity should allow to code your
wish using something like:
#macro( mywidget $map )
<h1>Hello $map.foo and $map.bar</h1>
#end
From my template I would call:
#set( $bob = "mary")
#mywidget( { foo:$bob, bar:"alice" } )
Which would produce the same output you requested!
And the greatest thing is that this already works!
- I mean in theory; I havn't tested it yet :D
Geir, is the map syntax allowed in a macro call parameter?
- otherwise you will need to define a reference first:
#set( $params = { foo:$bob, bar:"alice" } )
#mywidget( $params )
Bert, What do you think? Do you agree? Try it out with the
nightly build and report back if it works. Thanks.
Cheers,
Christoph
Bert van Brakel wrote:
> Hi Guys.
>
> I like the idea of macros, however I would like to extend it some more.
> I would like to be able to set named variables for a macro. I will call
> them 'widgets'.
>
> A widget definition would be similiar to a macro with some changes:
>
> #widget( mywidget foo=$first bar=$second )
> <h1>Hello $first and $second</h1>
> #end
Some polishing...
Why are you proposing to map foo to first? It makes no sense
to use two different names to refer to the same value: why
does the caller need to use foo= and the widget body $first?
In other threads people where proposing to use this syntax to
define defaults:
#widget( mywidget $foo="missing" $bar="none" )
<h1>Hello $foo and $bar</h1>
#end
#set( $bob = "mary")
#mywidget( $foo=$bob )
Would output
<h1>Hello mary and none</h1>
Since $bar was not defined, thus uses the default.
>
> From my template I would call:
>
> #set( $bob = "mary")
> #widget( mywidget foo=$bob bar="alice" )
>
> Which would produce:
>
> <h1>Hello mary and alice</h1>
>
> A slightly larger example could be:
>
> as a widget call:
>
> #widget( hobbiesTable title="Hobbies Table"
> onMouseOver="Javascript:jump" linker="$linker" items="${hobbies}"
> bgcolor="blue" footer="Table 3")
>
> or as a macro call:
>
> #macro( hobbiesTable "Hobbies Table" ${hobbies} "Javascript:jump"
> $linker "blue" "Table 3")
>
> The widget one is obviously much longer but also a lot clearer. It is
> easier to see what is set without having to lookup the macro and count
> the variable position. Order of the variables isn't important, and if
> more are added they can be put anywhere in the widget definition without
> affecting templates which already use it.
>
> variables which aren't set are null.
>
> So spec is:
>
> #widget( [widget-name [var-name=[local-var-name]]* ] )
>
> #end
>
> I really don't have a clue how the internals of velocity work so I don't
> know how hard it is to implement, but it's something that I've been
> wanting for quite some time and haven't found any other way to do. To my
> mind it doesn't break velocity prinicipals, and from the templates
> designers point of view is very easy to use.
>
>
> Thanks for listening.
>
> -Bert
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
>
--
:) Christoph Reck
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by Bert van Brakel <be...@tuaworks.co.nz>.
See my comments further down
Geir Magnusson Jr. wrote:
<snip>
> I assume you would really want
>
> #widget( mywidget foo=$a bar=$b )
> <h1>Hello $foo and $bar</h1>
> #end
>
> for clarity? (Minor academic quibble)
>
whatever works, it doesn't bother me.
> [SNIP]
>
> We've talked about this before. I do wonder if this would be
> confusing, as Christoph pointed out.
>
> Another options, should we want to support this, is keep it the same :
>
> #macro( thingy $foo $bar )
> Hi $foo $bar!
> #end
>
> and only change the *calling* approach :
>
> #thingy( foo=$myvar )
>
I still like the idea of being able to seperate local variables from the
arg names. (mentioned in my last email) thought I'm willing to
compromise. Anything is better than position based arguments.
> I do still think this will be confusing, looking at it here...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Wish for a new directive and a modified macro definition
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, October 29, 2003, at 01:36 AM, Bert van Brakel wrote:
> Hi Guys.
>
> I like the idea of macros, however I would like to extend it some
> more. I would like to be able to set named variables for a macro. I
> will call them 'widgets'.
>
> A widget definition would be similiar to a macro with some changes:
>
> #widget( mywidget foo=$first bar=$second )
> <h1>Hello $first and $second</h1>
> #end
>
I assume you would really want
#widget( mywidget foo=$a bar=$b )
<h1>Hello $foo and $bar</h1>
#end
for clarity? (Minor academic quibble)
[SNIP]
We've talked about this before. I do wonder if this would be
confusing, as Christoph pointed out.
Another options, should we want to support this, is keep it the same :
#macro( thingy $foo $bar )
Hi $foo $bar!
#end
and only change the *calling* approach :
#thingy( foo=$myvar )
I do still think this will be confusing, looking at it here...
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org