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 -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 7:04 AM To: Struts Developers List Subject: Re: Multiple controller servlets Donnie Hale wrote: > Re: the proposed interface - I'd like to see one, perhaps a base interface > for what you're proposing, which has access to everything for which the > current request isn't needed. And that's most of those elements. That way > all Struts elements that need the non-request-based resources can get at > them without having to have a request around to do it. Also, they'll be > there and accessible apart from a request anyway, so they should probably be > accessible. If you wanted to take a pass as a base implementation of the interface I outlined, that would be great. As you know, it could have immediate application in VelServlet, since they could pass it the request and get a handy API to the Struts resoruces in return. I would be very much in favor of a classic, step-wise refinement of ActionServlet that started with techniques like Extract Method and Extract Class, to first make the current design easier to follow and extend. Examples being the proposed ActionResource interface and the suggestion of an ActionProcess class for the process* methods. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ ---------- public interface ActionResources { public void setResourceRequest(HttpServletRequest request); public DataSource getDataSource(); public ActionErrors getActionErrors(); public Throwable getException(); public ActionFormBeans getActionFormBeans(); public ActionForwards getActionForwards(); public Locale getLocale(); public ActionMappings getActionMappings(); public MessageResources getMessageResouces(); public DiskMultipartRequestHandler getMultipartHandler(); public ActionServlet getActionServlet(); public Servlet getServlet(); public String getToken(); public ActionForm getActionForm(String name); public ActionForward getActionForward(String name); public ActionMapping getActionMapping(String name); public ActionMapping getCurrentMapping(); public ActionForm getCurrentActionForm(); } ---------- 3) There should definately be a ActionServletProcess interface, and associated base class implementations. The ActionServlet should be able to choose between a conventional and multipart process now, and others later. (Say, a VelocityProcess.) ---------- -- 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]>
