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