Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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,
Re: [Proposal] ActionFactory refactoring
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]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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]
Re: [Proposal] ActionFactory refactoring
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
Quoting Don Brown [EMAIL PROTECTED]: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] ActionFactory refactoring
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
