struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
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
> (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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message