Yeah, I wasn't sure what to call them either. I think it would be nice to
have one that will create the form from the config, no matter what type it
is, but still have others that create the specific type. This is mostly
useful for testing as it makes it easy to create dynaforms, a feature I've
been hearing a lot. Of course, it could just be two methods, and if you
just wanted a dynaform, create a FormBeanConfig and set dynamic to true.
As for when, it doesn't matter. I could easily put it in over the
weekend, code and tests, but if we are trying to get 1.2 out the door, it
can wait.
Don
On Fri, 2 Jan 2004, Martin Cooper wrote:
> 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
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org