I had originally thought we might start posting an ActionResources object in the request, so it would be there when we started to refactor the tag extensions, and also for the use of other presentation systems like Velocity templates. So, for a time, it would really be redundant, and could just getting from the contexts things that other components now get directly. But once the tag extensions were refactored to use it instead, it would open the door for multiple ActionServlets, each sending down their own instances of the ActionResources object.
I wouldn't change the setServlet methods at first, but add others that used the other object. Then once everything is in place, the old methods could be bypassed, deprecated, and eventually removed. We have to be careful in this, since we don't know what other developers are doing. So, we need to look for opportunities to deprecate a method for a time, before removing it. We should really try to put a release between any final changes to the API. Donnie Hale wrote: > > Ted, > > The stepwise refinement sounds like a reasonable way to go. I've got a good > chunk of one definite piece of that done - a "resource repository", which > would implement most of your proposed interface (it has no knowledge of > requests at present); and a "config handler", which reads servlet init > parms, struts-config.xml, and web.xml and populates the resource repository. > > To make sure I'm on the same page, a reference to an object implementing > your interface would be what's passed to the varions Action*.setServlet > methods instead of the ActionServlet. To make sense, all those method names > would need changed. Is that right? > > Any other input? > > Thanks, > > Donnie -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
