struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [Proposal] ActionFactory refactoring
Date Fri, 02 Jan 2004 22:08:53 GMT
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
> (, 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:
> Don
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message