You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/01/02 21:44:33 UTC
[Proposal] ActionFactory refactoring
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
Re: [Proposal] ActionFactory refactoring
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Don Brown <mr...@twdata.org>:
> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
>
The idea of factories for all Struts objects is an appealing one (I don't buy
the "too hard to teach" assertion either -- if you don't like teaching it, go
tell the GoF that they've got things all wrong :-). The idea of a single
factory for all of them isn't quite so appealing -- every time we want to add a
new Struts API object, we need to go back and modify the standard factory
class, which is messy.
One interesting approach to this would be to add a responsibility to the
existing set of FooConfig objects, adding an appropriate create method to each.
After all, if you want a specialized type of Action or ActionForm object,
you're probably going to need someplace to store extra configuration
information also, and the config object is exactly where you'd want to add
those properties. Instead of createDynaActionForm() and
createDefaultActionForm(), then, we'd simply have createActionForm() on the
FormBeanConfig class, and it would do the right thing. Using this approach,
configuring a specialized config bean class automatically configures a new
factory method as well, so you don't have to change two configuration settings
in struts-config.xml either.
An additional decision related to this whole condept, of course, is whether we
stick with the pure JavaBeans style object creation (zero-args constructor,
configure everything with property setters) or something like what Pico wants
(everything configured by arguments to the constructor). I've dealt with
enough tools vendors in the last couple of years to be convinced that the
former (JavaBeans style) is *substantially* easier to build tools for, and
would therefore favor continuing that design pattern for any kinds of objects
(and object factories) that we create in the future.
Craig McClanahan
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by BaTien Duong <ba...@dbgroups.com>.
Vic Cekvenich wrote:
>
>
> Don Brown wrote:
> It would take probably a few hours
>
>> to code so little effort is "wasted" when the struts-chain move takes
>> place.
>>
>
> I think that is the key at the end of the day. I think it be more
> effective the few hours be spent on integrating IoC into struts-chain....
Yes, integration of Struts-chain and IoC seems to hold a key for
managing a group of services that are passed via Struts-Chain as a
controller. I am exploring this with PicoContainer (using
DefaultLifeCyclePicoContainer which provides both life cycle management
and Config object).
BaTien
DBGROUPS
> but I do not need to remind anyone I am not a commiter, and even then
> each comiter can commit what they please, but I would rather see a
> design of IoC in CoR. If CoR already does digester, it can't be to far
> away from some level of alpha. I think it easier to work with a clean
> sheet of paper, but your preference, thanks for contributions.
> Maybe if there is a way to create a commons-IoC-api of interfaces that
> could be implemented as Nano, Hivemind, etc. and .... I duno.
>
> .V
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Proposal] ActionFactory refactoring
Posted by Vic Cekvenich <ce...@basebeans.com>.
Don Brown wrote:
It would take probably a few hours
> to code so little effort is "wasted" when the struts-chain move takes
> place.
>
I think that is the key at the end of the day. I think it be more
effective the few hours be spent on integrating IoC into
struts-chain.... but I do not need to remind anyone I am not a commiter,
and even then each comiter can commit what they please, but I would
rather see a design of IoC in CoR. If CoR already does digester, it
can't be to far away from some level of alpha. I think it easier to work
with a clean sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that
could be implemented as Nano, Hivemind, etc. and .... I duno.
.V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by Don Brown <mr...@twdata.org>.
On Fri, 2 Jan 2004, Vic Cekvenich wrote:
> So here are comments:
> - I like IoC idea! I prefer Nano, Hivemind or something else Jakarta
> based. I have been using HiveMind on projects and it is very nice.
Exactly my point. Abstracting object creating into a factory would allow
you to create a factory that uses HiveMind. The IoC implementation
I mentioned wouldn't be a part of Struts, but rather for a Spring
plugin project I'm working on (http://struts.sf.net/struts-spring).
> - I do not like any kind of factory. It's harder to teach and maintain
> then just new(). Factory and pool had it's place in JDK 1.3, but a new()
> is not bad in 1.4. Besides we know the type of object is comming, so no
> reason for factory, it would just add complexity.
Perhaps we are speaking about different factories... All a factory
pattern does is hide the object creation details, not necessarily object
pooling which I'm not suggesting at all. This allows objects to be
created and therefore managed by custom code which could be an IoC impl or
a user's custom object factory. Furthermore, it makes it easy to change
class implementation either through a different interface impl or
subclass.
Finally, very few Struts apps would use their own factory, as this is more
of an internal refactoring. If anything, I think it would reduce
complexity as it cuts a section of code out of the huge RequestUtils.
> - I like what Struts chain does, it's simple and clever and it shows
> people how to create their own custom action that extend base action
> with the user base. That should be the starting point and improvments
> should be based on it, IMO. For example, calls from there to IoC. An IoC
Yes, with Struts chain, you would simply replace the command that creates
an action or action form, but still that duplicates logic. A simple
factory only handles creation, not checking to see if one already exists
like in the case of form beans.
More importantly, Struts chain isn't used now. RequestProcessor is. This
refactoring is fairly simple, backwards-compatible, and imposes zero or
little changes the user would notice. It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
> DAO that populates a XMLFormBean Document. Digester could be called via
> IoC from CoR. I kind of think IoC is something users should do as calls
> from Strut's CoR. I do have a question if struts chain already reads
> digester or there is code someplace that does it or if I want to play
> with it I have to read mapping by myslef?
commons-chain contains ConfigParser, which uses the digester to build
chains from XML, however this is completely optional. It is very easy to
build chains manually or from some other config source like a database.
The Struts-chain uses the ConfigParser to load its configuration.
Don
>
> .V
>
>
> ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other
> light weight service implementation.
>
> 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
Re: [Proposal] ActionFactory refactoring
Posted by Vic Cekvenich <ce...@basebeans.com>.
So here are comments:
- I like IoC idea! I prefer Nano, Hivemind or something else Jakarta
based. I have been using HiveMind on projects and it is very nice.
- I do not like any kind of factory. It's harder to teach and maintain
then just new(). Factory and pool had it's place in JDK 1.3, but a new()
is not bad in 1.4. Besides we know the type of object is comming, so no
reason for factory, it would just add complexity.
- I like what Struts chain does, it's simple and clever and it shows
people how to create their own custom action that extend base action
with the user base. That should be the starting point and improvments
should be based on it, IMO. For example, calls from there to IoC. An IoC
DAO that populates a XMLFormBean Document. Digester could be called via
IoC from CoR. I kind of think IoC is something users should do as calls
from Strut's CoR. I do have a question if struts chain already reads
digester or there is code someplace that does it or if I want to play
with it I have to read mapping by myslef?
.V
ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other
light weight service implementation.
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
Re: [Proposal] ActionFactory refactoring
Posted by Don Brown <mr...@twdata.org>.
Heh, in my first proposal, I mentioned these bugs by name and URL too :)
Don
On Fri, 2 Jan 2004, Ted Husted wrote:
> On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> > Ok, sounds good. I'll create a bugzilla entry and post the patches
> > there.
>
> Here's an old one that you could use:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23583
>
> -T.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Proposal] ActionFactory refactoring
Posted by Ted Husted <hu...@apache.org>.
On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good. I'll create a bugzilla entry and post the patches
> there.
Here's an old one that you could use:
http://issues.apache.org/bugzilla/show_bug.cgi?id=23583
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by Ted Husted <hu...@apache.org>.
On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good. I'll create a bugzilla entry and post the patches
> there.
Speaking of factories ...
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by Don Brown <mr...@twdata.org>.
On Fri, 2 Jan 2004, Ted Husted wrote:
<snip />
> My one concern is the ActionServlet reference in the signature. I don't
> feel good about adding any more http dependencies to interfaces we may
> have to live with for some time. But it may be unavoidable, and when we
> do start encapsulating http, this whole she-bang might be encapsulated
> as well.
I agree, however, when we do write Servlets out of Struts, I think
everything will need to be rewritten, including this factory and the
objects it creates. Since this is more of an internal refactoring than a
new feature, I think we don't have to be as concerned about
backward-compatibility, especially since writing Servlets out of Struts
will break everything anyways. (of course by "writing Servlets out of
Struts" I mean removing Servlet dependencies in Struts)
>
> If you can do it over the weekend, and post a patch that people could
> review first, and you felt confident in the code, I would say that it
> could still make the 1.2.0 cut. I feel strongly that we need to address
> the remaining problem reports regarding pagePattern et cetera. I'm
> actively working on the module examples application now, but the
> application and the fixes aren't going to happen before Monday.
>
> Of course, an equally reasonable opinion would be to hold the patch for
> after the 1.2.0 roll, so that it can live in the nightly build for
> awhile. But it seems like a fairly straight-forward matter to me, and
> should either work or not.
Ok, sounds good. I'll create a bugzilla entry and post the patches there.
Don
>
> -Ted.
>
> On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> > 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
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [Proposal] ActionFactory refactoring
Posted by Ted Husted <hu...@apache.org>.
IMHO, if we were writing Struts today, then this definitely would have been a factory in the first place. So making it a factory now seems reasonable, so long as someone is willing to do the work :)
My one concern is the ActionServlet reference in the signature. I don't feel good about adding any more http dependencies to interfaces we may have to live with for some time. But it may be unavoidable, and when we do start encapsulating http, this whole she-bang might be encapsulated as well.
If you can do it over the weekend, and post a patch that people could review first, and you felt confident in the code, I would say that it could still make the 1.2.0 cut. I feel strongly that we need to address the remaining problem reports regarding pagePattern et cetera. I'm actively working on the module examples application now, but the application and the fixes aren't going to happen before Monday.
Of course, an equally reasonable opinion would be to hold the patch for after the 1.2.0 roll, so that it can live in the nightly build for awhile. But it seems like a fairly straight-forward matter to me, and should either work or not.
-Ted.
On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by Don Brown <mr...@twdata.org>.
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 <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [Proposal] ActionFactory refactoring
Posted by Martin Cooper <ma...@apache.org>.
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
Re: [Proposal] ActionFactory refactoring
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:44 AM -1000 1/2/04, Don Brown wrote:
>What if we extracted the creation of Actions and ActionForms (including
>DynaActionForms) into an ActionFactory, overridable by the user?
In general, I'm in favor. I disagree with Vic's assertion,
paraphrased "factories are too complicated; it's good enough to
directly call the constructor" -- certainly that is appropriate for
some classes, but by centralizing expertise for creating instances
within a single class, you have a lot more flexibility to make an
across-the-board change to what exactly which objects are created.
(Something to which Martin alluded while I was composing this
message.)
I won't elaborate too much at the risk of hijacking, but I wonder if
we could also use this as an easy step towards an API whereby an
Action could request an "output form" instance for pre-population.
(That is, the form bean which would back an html:form block in the
destination view, as opposed to the "input form" which encapsulates
the request parameters.)
This was one of the motivations for adding a view controller, which
we talked about in the fall, and which I looked at doing for a
little bit. A full-fledged view controller raised a lot of questions
which made me inclined to wait for struts-chain, but a simple
mechanism which boils down (for most users) to a method in Action or
ActionMapping like "getOutputForm(String)" might be a nice
compromise. Personally, if I could easily get an output form in an
Action, I could live a while longer without a separate class to
encapsulate my view stuff. The mechanism we use now is a horrible
hack.
OK, I'm afraid I've already elaborated too much... Back to the
specifics, I'm a little uneasy about the method to explicitly get a
DynaActionForm. Otherwise, I think it's likely to be helpful, and
likely to be a low-impact change.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org