Ted, I can see that. However, some of those collections are directly FastHashMaps, and some are wrappers like ActionFormBeans. I've thought that perhaps wrappers should be made for all of them to be consistent, and then ActionResources would be as you say - a means for accessing a reference which provides the underlying API.
Donnie -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Monday, December 03, 2001 10:38 PM To: Struts Developers List Subject: Re: Multiple controller servlets These wouldn't exist as such on the ActionResource interface I suggested. These are really just shortcuts to the API for the underlying resources, like formBeans.addFormBean(formBean); So, if someone wanted to do them through an ActionResources object, they could do the same thing actionResources.getFormBeans().addFormBean(formBean); I believe the real reason they are on ActionServlet is for the digester. The admin Actions are fun, but I doubt that they are used much, except for reload, which calls a different set of methods. But, again, my first thought for the ActionResource interface was to expose the resources to other components. The big ticket on ActionServlet would be to refactor those nasty process* methods into a coherent helper object. Donnie Hale wrote: > > 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 -- 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]>
