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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
