Re: Velocity View API for Struts [Phase 1] er... Phase 2.. i think.

[Nathan Bubna <na...@esha.com>]

[snip]
> Nathan,
> what I propose is really very very similar to want you just describe. With
> my proposed approach the above link could be written as
>
> <a
href="$link.setPath($url.forward("login")).addQueryData('action','checkAuth'
)">Login</a>
>
> The added benefit is that the link tool stays general purpose and can
> be used with or without Struts. It this really "extremly annoying"?

:-) yeah...  seriously, it would really bug me to have to do that.  and
since nothing is in stone yet, this is the time to be really picky, is it
not?  i really don't see sufficient reason to split such closely related
functions into two seperate tools, and i think to do so will come across as
confusing and clumsy to people using it (it sorta does to me already).  it
needn't be that complicated. (14 extra keystrokes and dealing w/two separate
tools)

> If we combine all the features of your proposed link tool with the
forward,
> action and baseRef methods of Struts, we would need another link tool that
is not
> strut-ified, thereby duplicating some functionality. I think there is some
> value in having tools that are orthogonal to each other.

yes, this is something to consider... we should not go around haphazardly
duplicating code, but i think this may be a situation where it makes sense
to do so.  I think it will be fine to keep a copy of the basic LinkTool in
the velocity-tools-view subproject (if anyone wants it there) and to have a
StrutsLinkTool in the velstruts package.  Ideally, we would be able to have
the StrutsLinkTool extend the LinkTool, but given the nature of LinkTool's
behaviour (instances are immutable and 'mutator' methods return new
instances) that would be ridiculous.  So, while you'll normally find me
against maintaining two copies of mostly identical code, this is an
exception.  Besides, since it only deals with URLs, the underlying code in
LinkTool should be extremely stable, so we should rarely (if ever) have to
worry about keeping the two classes in sync (or in backstreet boys :-P).

> Additionally, in many practical cases, the forward, action and baseRef
methods
> are used without adding query parameter explicitely (forms add the
parameters
> automatically, baseRefs don't need parameters.) I am just finishing a
Struts
> application where I never had the need to add query parameter explicitely.
I
> worked with hidden form fields, instead. Those can be manipulated in
JavaScript.
> This add to my believe that the synergies of a combined tool are not as
big
> as it might seem at first.

if you want to convince me of something, it's usually not a good idea to
discuss using things like JavaScript. :-)  maybe i'll be less averse to such
things when browser implementations are all standardized, but i doubt i'll
live to see that day! :-P

anyway, you're right that query data probably won't often be needed all that
often, but there are reasonable situations where it will be wanted, and to
do what you suggest even once is hack to me.  and though it's use may be
more or less infrequent, i feel it is something we should support with out
resorting to such a, in my opinion, hack solution.

> Makes any sense to you? Any opinions from others?

yeah, anyone else care to weigh in on this stuff?  or is it just me and gabe
out here talking to ourselves?

Nathan Bubna
nathan@esha.com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>