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