Off the top of my head (meaning I haven't thought through all of the possible ramifications yet ;), I like this idea. I know that when I added factories to Commons FileUpload, it took the ability to customise things to a level that just isn't possible with straight 'new' coding. I can see how the same would be true for Actions as well.
I'm not sure about the specific API you suggest. I assume by "default" you mean the non-dyna flavour? Something about the API doesn't "feel" right, but I'll try to give it some thought later and see if I can come up with anything better. BTW, I assume you're proposing this as a post-1.2.0 change? -- Martin Cooper On Fri, 2 Jan 2004, Don Brown wrote: > What if we extracted the creation of Actions and ActionForms (including > DynaActionForms) into an ActionFactory, overridable by the user? > > Here's the problem as I see it: there is no simple way for a user to plug > in their own code to manage the creation of actions and action > forms. The actual creation is handled by static methods in > RequestUtils, obviously not overridable, leaving the only option to > extend RequestProcessor and duplicate a lot of logic. > > Why would you want to plug in your own ActionFactory? My primary purpose > is to better integrate Inversion of Control (IoC), specifically Spring's > IoC, into Struts. By letting Spring create Struts objects, Spring can > handle any dependencies and configuration they need. Another use, as > stated in bug #23583 > (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a > factory that creates ActionForms using JavaAssist at runtime. Finally, > this factory would be an easy way for the user to create their own > DynaActionForms, particularly useful for unit testing. > > Impact: This would have no impact on current Struts applications as it is > an internal refactoring and default behavior would remain the same. > Extensions that include custom RequestProcessors or interfere with object > creation might be affected. > > Configuration: I'd recommend another attribute in the <controller /> > element in struts-config, possibily named "actionFactoryClass", pointing > to the new ActionFactory implementation to use. If none specified, a > default factory which mimics current behavior would be used. > > This is my proposed interface: > > public interface ActionFactory { > > public Action createAction(ActionServlet servlet); > > public DynaActionForm createDynaActionForm(ActionServlet servlet, > FormBeanConfig config, > ActionConfig mapping); > > public ActionForm createDefaultActionForm(ActionServlet, > FormBeanConfig config); > > > public ActionForm createActionForm(ActionServlet servlet, > FormBeanConfig config, > ActionConfig mapping); > > } > > Note createActionForm() creates either a DynaActionForm or ActionForm > depending on the config. > > Comments? Obviously, I'd perform the refactorings if this feature was > agreed upon. Future targets for factories could include config objects: > http://issues.apache.org/bugzilla/show_bug.cgi?id=13638 > > Don > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
