Hi, Don, I'm thinking out loud here.
I have been chewing on this because I am in a mode where I have to think about where to put my energies the next few years. So, I might as well jump in here and see what people think. At least I know enough to listen. I like what Vic was saying about CoR and IoC, by the way. Inversion of control is merely that: inversion of control. You pass control of some choice or process over to the framework. As such, IoC is really so general as to be less than really helpful on any particulars, even where the term "IoC" is an accurate description of what is going on. That is why Martin Fowler uses Dependency Injection instead of IoC in his well-known piece on the same. When you have a "helper" interface, e.g. Fowler's MovieFinder interface, and you want to be able to use different implementations in a framework, Fowler calls that Dependency Injection. Essentially, this allows you to use the same code internally while passing the name or type of the object which implements the interface to some assembly mechanism in the container. Sometimes you want to do this, viz. have the choice of using multiple implementations and having the container assembled with your choice, usually using configuration xml and some equivalent of Pico's NanoContainer to manage the xml assembly. Or, you can use a Service Locator to do the same thing. Where you just want to use one implementation, I prefer using or at least am considering prefering using hot deploy. This means that you don't have to use IoC or Service Locator or anything else to have differing implementations in the same framework. What is more, not only are there, as Craig McClanahan says, "fewer moving parts", but also you can choose to employ differing implementations of the same interface with different names (think Action subclasses) and each of these can then be hot deployed as well. Lastly, if you are using CoR you can also use hot deploy to allow varying implementations. As a result, I am starting to think that hot deploy is a better solution than either service locator or dependency injection to the problem of allowing differing implementations of interfaces in an interface. Anyone that has further thoughts on this, I would be more than interested. With hot deploy, instead of switching the implementation and the name of the implementation class, e.g. ColonSeparatedMovieFinder for DatabaseMovieFinder, you just have an implementation called MovieFinderImplementation (or whatever you want, e.g. X) and a MovieFinderImplementationHotFactory for getting object instance implementations of the MovieFinder interfaces. Conceivably, in fact, you can give people differing implementations with the same name by simply putting them in different directories: no problem. This means that the code can be dynamic and alterable at will and that there need be no changes anywhere if you don't want there to be other than dumping the new MovieFinderImplemenation.class in some directory somewhere. Anyway, I am starting to fall in love with this idea for the moment. LOL Any experience on this out there? I would like a way to update objects in this sort of design without killing garbage collection by maintaining references. Any ideas on that? Jack On Wed, 24 Nov 2004 11:08:46 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > I look at technology as solutions to problems. IoC solves the problem > of how can I define and configure a component external to the component > and calling code, and CoR tackles the problem of a how can I define a > process or sequence of processes in a pluggable manner. > > True, both patterns have a "pluggable" property, but both a HashMap and > a SQL database have a "lookup" property. I think what you are getting > at is, in Struts, we need a way to allow the framework to be easily > customized by both framework extension projects and users. Both IoC and > CoR help us meet that goal, but by solving two different problems that > work against "pluggability". In Struts, I see the need for allowing the > user to have more control over the process of events, as well as what > components are used by that process. So yes, one goal perhaps, but two > different problems being solved in two different ways. > > Don > > > > Dakota Jack wrote: > > >Without disagreeing with anything you have said, Don, I think the > >confusion is caused in part by the fact that CoR is anticipated in > >part for its pluggable nature. In this respect, there is a real > >connection in functionality between CoR and IoC that is not as > >attenuated as the one between HashMap and a SQL database but more like > >a properties file and a SQL database? You think? > > > >Jack > > > > > >On Wed, 24 Nov 2004 10:44:30 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > > > > > >>Not you personally BaTien, I don't understand why some people seem to > >>confuse Inversion of Control (IoC) and Chain of Responsibility (CoR), > >>and worse, think they are somehow solving the same problem. IoC helps > >>us create components by managing their lifecycle and providing their > >>dependencies. CoR defines a process that let's us flexibly specify what > >>code to execute in what order. > >> > >>Sure, commons-chain does provide the default capability to create > >>commands and configure them with simple properties, but that isn't its > >>purpose and would certainly be replaced in any moderately complex usage, > >>most likely by some sort of IoC. It's like saying a HashMap conflicts > >>with a SQL database as they both store data. They are two very > >>different things with very different problems they are trying to solve. > >> > >>Don > >> > >> > >> > >>BaTien Duong wrote: > >> > >> > >> > >>>Craig McClanahan wrote: > >>> > >>> > >>> > >>>>On Tue, 23 Nov 2004 14:20:02 -0600, Joe Germuska <[EMAIL PROTECTED]> > >>>>wrote: > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>>>I need to have a hook into processValidate() on validation failure. > >>>>>> > >>>>>>Currently that can only be done by copy-and-pasting the > >>>>>>processValidate() > >>>>>>method from RequestProcessor into a subclass and sticking a hook > >>>>>>into the > >>>>>>middle of the code. > >>>>>> > >>>>>>When I asked about this on the dev list long ago, it was confirmed > >>>>>>that > >>>>>>there was no other way to do this, but that chain would eventually > >>>>>>provide > >>>>>>this flexibility. > >>>>>> > >>>>>>If the chain isn't configured at a fine-grain level, then it's not > >>>>>>all that > >>>>>>much more functional than the existing RequestProcessor. > >>>>>> > >>>>>> > >>>>>> > >>>>>The chain is configured at as fine-grained a level as you like, in > >>>>>XML. Hubert is talking about configuring the chain programatically > >>>>>as well, or at least in some way independent of the configuration of > >>>>>the primary processing chain. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Programmatic configuration is certainly feasible ... there's no > >>>>requirement in [chain] that you use the XML format at all. It's just > >>>>one option. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>Greetings and request expert advice: > >>> > >>>Commons-chain invented by Craig proves to be very flexible and work in > >>>conjuction with other great technonologies. What i am trying to figure > >>>out is a proper and practical places for using CoR and IoC (such as > >>>Spring framework) in the construction and configuration of software > >>>objects. I put out some of my preliminary thinking and hope some > >>>experts care to add more arguments to enlighten us. > >>> > >>>1) Both CoR and IoC (and also Jsf setter injection) enable the > >>>configuration and linking objects via XML metadata. But IoC allows the > >>>object configuration at a finer level of object attributes and take > >>>care of the objects declared as singleton. In this sense, IoC is finer > >>>grain than CoR in object creation, configuration and management. > >>> > >>>2) CoR is very light weight and appropriate for programmatically > >>>created processes. It does not not have the complexity and the depth > >>>of plug-in features as Spring IoC. > >>> > >>>3) CoR is finer grain than IoC in the construction and rounting of > >>>services within and between software layers, while IoC is aprropriate > >>>at the application level. > >>> > >>>4) If we want to combine Jsf as view controller, Spring IoC and > >>>commons-chain CoR, a practical infrastructure may be something like > >>>followings: > >>> a) Jsf as a view controller takes care of objects directly related > >>>to User Interface (UI) > >>> b) Spring IoC takes the responsibility of object creation, > >>>especially singletons and fine grain configurations of objects not > >>>directly related to UI. This is a proper choice of configuration if > >>>other features of Spring framework such as application level event and > >>>aop are used. > >>> c) CoR is used to construct Front Controller a la pattern of Struts > >>>of each software module, the rounting of services among modules, and > >>>action commands (or chain) of specialized services in each service > >>>module. It programmatically links created components from IoC to a > >>>finer grain at each software module, which holds the module Catalog of > >>>commands. > >>> d) User session is a proper place for programmatically interactions > >>>of Jsf, IoC and CoR objects. For example user generated events from > >>>Jsf is linked through a CoR adapter to dispatch action command as a > >>>request to appropriate software module (such as > >>>authentication/authorization, portlet, service, etc) whose responses > >>>are rendered through Jsf view controller. > >>> > >>>BaTien > >>>DBGROUPS > >>> > >>> > >>> > >>> > >>> > >>>>>As long as you're willing to copy the base chain-config.xml file and > >>>>>make a few modifications, then you could simply add your own command > >>>>>which retrieves a value from the context under a well-known key and > >>>>>inspects the value to see if validation passed or not. This exact > >>>>>logic is the first thing executed in the CreateAction's execute > >>>>>method, which doesn't lookup or create an action unless the form > >>>>>validated. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>There's actually quite a few different ways to approach this, > >>>>including the "optionally invoke some other command at this point" > >>>>mentioned earlier in the thread, so you don't even *have* to > >>>>cut-n-paste the standard version of the chain. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>You can start experimenting with commons-chain and struts-chain from > >>>>>CVS Head if you want to see what's going on. You don't have to wait > >>>>>for Struts 1.3. > >>>>> > >>>>> > >>>>> > >>>>Indeed, Struts-Chain directly illustrates the fine-grained approach to > >>>>defining the standard request processing chain that Joe describes. > >>>>Nightly builds are available at: > >>>> > >>>>http://cvs.apache.org/builds/jakarta-struts/nightly/struts-chain/ > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Joe > >>>>> > >>>>> > >>>>> > >>>>> > >>>>Craig > >>>> > >>>>--------------------------------------------------------------------- > >>>>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] > >> > >> > >> > >> > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]