Ted, There are a number of public methods on ActionServlet right now like:
addDataSource addFormBean addForward addMapping Some of them are used in various actions package classes to do things dynamically. I'm guessing that there are deployed Struts apps out there which also use these methods as well. Do you have any thoughts on how this functionality should be supported? Would these be additional methods on your proposed interface? 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]>
