>>I'm just thinking that many of the components that we use may have wider user, and we should avoid binding things to the ActionServlet class. <<
I thought you all might say something like this and of course I agree. My intent is attempting to be pragmatic by providing a simple fix that will work within the 1.0.x stream. I just seems that these other good ideas may be more appropriate for the 1.1 stream; but maybe not. Since there seem to be agreement on the idea of a "resource" interface how does an actual design get agreed upon to be implemented or do people just submit random implementations to be figured out by committers? Tim W Wilson Eclipse WSED Architecture & Development internet: [EMAIL PROTECTED] (919) 254-0029 (TL 444-0029) "Donnie Hale" <[EMAIL PROTECTED]> on 11/27/2001 08:45:43 PM Please respond to "Struts Developers List" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> cc: Subject: RE: Multiple controller servlets >>I'm just thinking that many of the components that we use may have wider user, and we should avoid binding things to the ActionServlet class. << I agree strongly with this. Nearly all of the collections, maps, etc. which are initialized by and accessed via the ActionServlet should instead be accessed via a "ServiceManager" (which may conflict with the other notion of "ServiceManager" that's been discussed recently). ActionServlet would be a client of that singleton object just like anything else in the application that wanted to use it. Off the top of my head, it would be terrific if ActionServlet.init() just called ServiceManager.init(), passing it the fully-qualfied name of the config file. Correspondingly, as was discussed recently, a "ContextManager" (wonderful generic names, huh? :) would become the central point of access for all the stuff that's getting shoved in the request/session/servlet contexts. It would use those contexts as needed, but it would allow for a more structured approach to use of the contexts as opposed to the current, seemingly somewhat random use of them for any kind of object that comes along. Ideally, to my mind, anything that can be accessed via the "ServiceManager" wouldn't get shoved in any of the contexts. FWIW... Donnie -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 7:23 PM To: Struts Developers List Subject: Re: Multiple controller servlets We just changed the ActionForm to use a wrapper object, rather than the original, since exposing the ActionServlet this way can be exploited. I'm just thinking that many of the components that we use may have wider user, and we should avoid binding things to the ActionServlet class. Avoding this reduces the coupling between the other components and the ActionServlet, which could then open the door for the form tags to be used by some other servlet entirely. Another framework could provide the "resource bean", but be using it's own servlet class. Taking on their own, most components in the framework are fairly generic, and could be "mixed and matched". I agree that exposing the servlet would be a quicker fix, but we might want to learn the lessons of Turbine, and avoid coupling other classes to our controller. In the end, the only way to access the resources could be through the bean in the request. The form tags are probably calling getServlet because the other resources it wants are not properly exposed. This way, the tag could cache the resource bean, and just get what it asks for. Tim W Wilson wrote: > > Ted, I appreciate the feedback, thx. > > The public interface of ActionServlet is already used by ActionForm, > ActionMapping and Action so it seems natural for it to be used by the > taglibs and get it to them through the request like everything else. In > fact, FormTag itself actually caches the servlet instance retrieved through > the mapping.getServlet() so that it can set it into ActionForm instance > that it creates if a previous one is not found. On the whole it just seems > a lot simpler to have all components use the public ActionServlet interface > and not have multiple ways of accessing these resources. > > Tim W Wilson > Eclipse WSED Architecture & Development > internet: [EMAIL PROTECTED] > (919) 254-0029 (TL 444-0029) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] > For additional commands, e-mail: <mailto:[EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED] > For additional commands, e-mail: <mailto:[EMAIL PROTECTED] > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
