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