On 10/13/05, Ted Husted <[EMAIL PROTECTED]> wrote: > On 10/13/05, Nathan Bubna <[EMAIL PROTECTED]> wrote: > > By the way, if i can take this opportunity to do so, VelocityStruts is > > in need of some upgrades for the Struts 1.2 and/or 1.3 series. I've > > not been free to use Struts in my paid work and volunteer time has > > been scarce, so i'm not up to speed on the newer versions. If anyone > > is interested in helping out, that would much appreciated. :) > > For Struts 1.3, I wouldn't trying to make the VelocityStruts tools obsolete :)
? > The idea with this 1.3 agenda item > > * ViewContext - A Commons Chain Context that implements the combined > VelocityStruts logical API (same signatures). > > is to eliminate the need for tags to wander all over the contexts > looking for this and that. Instead, it will all be in a single object > in request scope. (Which in turn might access other objects in session > or application scope.) > > Accessing Struts components directly would be deprecated, and support > removed in a later release. Access through the ViewContext would be > cannonical, and tag libs support Struts would need to upgrade. sounds good. but i'm not sure i follow totally... has this been done? or is it just planned? really, i'm not up to speed on Struts 1.3 at all. > Since VelocityStruts has already solved this problem :), I'd like to > adopt and adapt that code so that it is part of the Core framework. just want to be sure i understand here... are you wanting to bring Velocity(Tools) integration code over to the Core or merely the code we use to access Struts resources? granted, the two aren't clearly delineated in VelocityStruts, but in general the integration-ish code is in the actual tool classes and exists to put a Velocity(Tools) friendly API on Struts resources. the StrutsUtils class is largely where we access struts resources (and i believe it originated in code from you. :) > The big implementation question would be whether to use several > objects, as Velocity Struts does, or just roll them back into one. yep. that's a big one. we break them up because it seems conceptually clearer and simpler to have $link, $text, $errors, and such than to have the extra layer of $struts.link, $struts.text, and so on. but this may not matter so much if you are presenting an API to tag (or tool) developers rather than page designers. also, a big advantage of splitting ours up is that we are then able to have the StrutsLinkTool extend VelocityView's LinkTool and thus leverage that code, and we can also offer the SecureLinkTool as an optional drop in replacement for the StrutsLinkTool. of course, on the latter, i suppose you could combine them all and make the https/http option be a matter of tool config rather than tool choice. > -Ted. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
