- 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]
