Named macro parameters

[Christopher Schultz <ch...@christopherschultz.net>]

All,

I was just reminded of the horror of the Struts 2 implementation of
their tag library in Velocity. Mind you, I think the S2 guys did a
/great/ job of creating implementations of their library in JSP,
Freemarker, and Velocity, but the Velocity implementation just doesn't
feel right.

Here's what you see in JSP (and, do a large degree, Freemarker is nearly
identical):

<struts:someTag foo="bar" baz="whatever">
...

In Velocity, since named macro parameters are not supported, you get
something like this:

#strutsSomeTag("foo=bar" "baz=whatever")

(See http://struts.apache.org/2.0.11.2/docs/velocity-tags.html for
reference).

While that does get the job done, you can see that, for every evaluation
of the macro, the S2 implementation has to re-parse the strings that are
being passed-in in order to grab the parameter value and then assign it
to the actual attribute on whatever object that represents the tag itself.

Performance-wise, it's a hog. That means that Velocity starts with a
built-in performance disadvantage when it comes to using S2. It's also
visually cumbersome, since the attribute AND value are all within the
quotes. Perhaps I'm being nit-picky, but I've considered abandoning
Velocity for my next Struts project (which will be using S2). I would
imagine that I'm not the only one who would come to this conclusion.

So, my question is: can we do better? I wonder if there's a way to add
something to the Velocity language that would give users a more
tag-oriented syntax that would "feel" more like JSP/Fm and yield better
performance.

-chris

Re: Named macro parameters

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

Nathan Bubna wrote:
> i think [on-the-fly Map creation) was not available when they started.  whether they know
> now, i don't know.  they haven't kept pace with VelocityTools at all
> (they appear to be on Tools 1.1 still), so i'd be surprised to find
> they use Velocity 1.5.  i hope they at least recommend Velocity 1.4...

I don't think they "use" velocity-tools at all. I think it's up to the
user to determine the versions to use, which may be why they don't
require the on-the-fly Map support. Using a different macro library
should be all that is necessary to switch between their current
implementation and a Map-based one.

In case anyone is interested, I have posted to struts-user asking about
the potential for a Map-based implementation. Here is the thread for
anyone who wants to read it:

http://www.nabble.com/-S2--Velocity-Integration-td19520425.html

I'll be cross-posting to the struts-dev list as suggested by Jeremy
Evans. Yet another mailing list subscription... :(

-chris

Re: Named macro parameters

[Nathan Bubna <nb...@gmail.com>]

On Tue, Sep 16, 2008 at 1:46 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nathan,
>
> Nathan Bubna wrote:
>> #whatever({ 'foo' : 'bar', "baz" : "bat" })
>
> I didn't realize that this syntax was possible. I'm still on Velocity
> 1.4 where, for instance, you can't do this:
>
> #whatever($velocityCount + 1)
>
> I just assumed that creating a Map on the fly wasn't an option.

it was added in v1.5

> I wonder if the Struts guys knew this was possible... it's a much more
> elegant way to do it and results in faster rendering.

i think it was not available when they started.  whether they know
now, i don't know.  they haven't kept pace with VelocityTools at all
(they appear to be on Tools 1.1 still), so i'd be surprised to find
they use Velocity 1.5.  i hope they at least recommend Velocity 1.4...

> -chris
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Named macro parameters

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

Nathan Bubna wrote:
> #whatever({ 'foo' : 'bar', "baz" : "bat" })

I didn't realize that this syntax was possible. I'm still on Velocity
1.4 where, for instance, you can't do this:

#whatever($velocityCount + 1)

I just assumed that creating a Map on the fly wasn't an option.

I wonder if the Struts guys knew this was possible... it's a much more
elegant way to do it and results in faster rendering.

-chris

Re: Named macro parameters

[Nathan Bubna <nb...@gmail.com>]

On Mon, Sep 15, 2008 at 2:57 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> Nathan,
>
> Nathan Bubna wrote:
>> On Mon, Sep 15, 2008 at 8:53 AM, Will Glass-Husain
>> <wg...@gmail.com> wrote:
>>> Wouldn't it be more appropriate to pass in a map of parameters?
>>
>> heh.  yeah, why don't they do that?
>
> I'm sure they don't do that because of the syntactic differences.
>
> Is it possible to call a macro with an in-line Map definition like this:
>
> #whatever(["foo"=>"bar", "baz"=>"bat", ...])

yes, but the syntax is:

#whatever({ 'foo' : 'bar', "baz" : "bat" })

i'm sure a custom directive would/should take an inline map as well.

> ?
>
> -chris
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Named macro parameters

[Christopher Schultz <ch...@christopherschultz.net>]

Nathan,

Nathan Bubna wrote:
> On Mon, Sep 15, 2008 at 8:53 AM, Will Glass-Husain
> <wg...@gmail.com> wrote:
>> Wouldn't it be more appropriate to pass in a map of parameters?
> 
> heh.  yeah, why don't they do that?

I'm sure they don't do that because of the syntactic differences.

Is it possible to call a macro with an in-line Map definition like this:

#whatever(["foo"=>"bar", "baz"=>"bat", ...])

?

-chris

Re: Named macro parameters

[Nathan Bubna <nb...@gmail.com>]

On Mon, Sep 15, 2008 at 8:53 AM, Will Glass-Husain
<wg...@gmail.com> wrote:
> Wouldn't it be more appropriate to pass in a map of parameters?

heh.  yeah, why don't they do that?

> On Fri, Sep 12, 2008 at 9:04 AM, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> All,
>>
>> I was just reminded of the horror of the Struts 2 implementation of
>> their tag library in Velocity. Mind you, I think the S2 guys did a
>> /great/ job of creating implementations of their library in JSP,
>> Freemarker, and Velocity, but the Velocity implementation just doesn't
>> feel right.
>>
>> Here's what you see in JSP (and, do a large degree, Freemarker is nearly
>> identical):
>>
>> <struts:someTag foo="bar" baz="whatever">
>> ...
>>
>> In Velocity, since named macro parameters are not supported, you get
>> something like this:
>>
>> #strutsSomeTag("foo=bar" "baz=whatever")
>>
>> (See http://struts.apache.org/2.0.11.2/docs/velocity-tags.html for
>> reference).
>>
>> While that does get the job done, you can see that, for every evaluation
>> of the macro, the S2 implementation has to re-parse the strings that are
>> being passed-in in order to grab the parameter value and then assign it
>> to the actual attribute on whatever object that represents the tag itself.
>>
>> Performance-wise, it's a hog. That means that Velocity starts with a
>> built-in performance disadvantage when it comes to using S2. It's also
>> visually cumbersome, since the attribute AND value are all within the
>> quotes. Perhaps I'm being nit-picky, but I've considered abandoning
>> Velocity for my next Struts project (which will be using S2). I would
>> imagine that I'm not the only one who would come to this conclusion.
>>
>> So, my question is: can we do better? I wonder if there's a way to add
>> something to the Velocity language that would give users a more
>> tag-oriented syntax that would "feel" more like JSP/Fm and yield better
>> performance.
>>
>> -chris
>>
>>
>
>
> --
> Forio Business Simulations
>
> Will Glass-Husain
> wglass@forio.com
> www.forio.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org

Re: Named macro parameters

[Will Glass-Husain <wg...@gmail.com>]

Wouldn't it be more appropriate to pass in a map of parameters?



On Fri, Sep 12, 2008 at 9:04 AM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> All,
>
> I was just reminded of the horror of the Struts 2 implementation of
> their tag library in Velocity. Mind you, I think the S2 guys did a
> /great/ job of creating implementations of their library in JSP,
> Freemarker, and Velocity, but the Velocity implementation just doesn't
> feel right.
>
> Here's what you see in JSP (and, do a large degree, Freemarker is nearly
> identical):
>
> <struts:someTag foo="bar" baz="whatever">
> ...
>
> In Velocity, since named macro parameters are not supported, you get
> something like this:
>
> #strutsSomeTag("foo=bar" "baz=whatever")
>
> (See http://struts.apache.org/2.0.11.2/docs/velocity-tags.html for
> reference).
>
> While that does get the job done, you can see that, for every evaluation
> of the macro, the S2 implementation has to re-parse the strings that are
> being passed-in in order to grab the parameter value and then assign it
> to the actual attribute on whatever object that represents the tag itself.
>
> Performance-wise, it's a hog. That means that Velocity starts with a
> built-in performance disadvantage when it comes to using S2. It's also
> visually cumbersome, since the attribute AND value are all within the
> quotes. Perhaps I'm being nit-picky, but I've considered abandoning
> Velocity for my next Struts project (which will be using S2). I would
> imagine that I'm not the only one who would come to this conclusion.
>
> So, my question is: can we do better? I wonder if there's a way to add
> something to the Velocity language that would give users a more
> tag-oriented syntax that would "feel" more like JSP/Fm and yield better
> performance.
>
> -chris
>
>


-- 
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

Re: Named macro parameters

[Nathan Bubna <nb...@gmail.com>]

I don't know offhand of an easy way to make things more JSP/FM-ish,
and honestly, i don't love the tag-type syntax.  So i'm pretty
unmotivated there.  As for performance, i think they could clean that
up w/o requiring us to implement new features.  They would just need
to give up the tag-ish approach and use tools.  I would recommend
fluent tools (self-or-subtool-returning) as replacements for the
one-line tags:

$someTool.foo("bar").baz("whatever")

and write directive(s) that extend/mimic Define but takes a call like
the above as the single argument and passes the body of the directive
to the tool via a public Self/SubTool body(Define.Block/String body)
method.  Then the tool can do whatever it wants with the body (e.g.
access literal or rendered versions, mess with its context before
rendering, etc).  I imagine it being used like:

#body( $someBodyTool.foo(true).baz(2) )
here's the body!
#end

or like this:

$someBodyTool.foo(true).baz(2).body("here's a body too")

Of course, i realize that i am biased in favor of a tool approach, but
that's because i honestly do consider it to be the best approach for
this sort of thing.  Tools offer more flexibility and innovation both
in implementation and in use.  They can be not-only scope-aware, but
can themselves be scoped.  Things returned by their methods can be
#set for reuse.  They can be passed to each other directly to make
interaction between them simpler.  With VelocityTools 2, you can even
put off instantiation until the tools are used, so there's very little
overhead for having as many tools as you want.   And also, is they
used tools, it would provide more parity with VelocityStruts and all
the other VelocityTools out there.  So, existing VelocityTools users
would find it easy and natural to move to Struts 2 (and Struts 2 users
might find it easier to branch out to using our other tools or their
own).

On Fri, Sep 12, 2008 at 9:04 AM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> All,
>
> I was just reminded of the horror of the Struts 2 implementation of
> their tag library in Velocity. Mind you, I think the S2 guys did a
> /great/ job of creating implementations of their library in JSP,
> Freemarker, and Velocity, but the Velocity implementation just doesn't
> feel right.
>
> Here's what you see in JSP (and, do a large degree, Freemarker is nearly
> identical):
>
> <struts:someTag foo="bar" baz="whatever">
> ...
>
> In Velocity, since named macro parameters are not supported, you get
> something like this:
>
> #strutsSomeTag("foo=bar" "baz=whatever")
>
> (See http://struts.apache.org/2.0.11.2/docs/velocity-tags.html for
> reference).
>
> While that does get the job done, you can see that, for every evaluation
> of the macro, the S2 implementation has to re-parse the strings that are
> being passed-in in order to grab the parameter value and then assign it
> to the actual attribute on whatever object that represents the tag itself.
>
> Performance-wise, it's a hog. That means that Velocity starts with a
> built-in performance disadvantage when it comes to using S2. It's also
> visually cumbersome, since the attribute AND value are all within the
> quotes. Perhaps I'm being nit-picky, but I've considered abandoning
> Velocity for my next Struts project (which will be using S2). I would
> imagine that I'm not the only one who would come to this conclusion.
>
> So, my question is: can we do better? I wonder if there's a way to add
> something to the Velocity language that would give users a more
> tag-oriented syntax that would "feel" more like JSP/Fm and yield better
> performance.
>
> -chris
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org