Well put, Sir. I think this about "does it". I would advocate not only the CoR coding now being done but also an eventual IoC using all three types of injection for the major components in Struts. This would be, I think, the "cat's meow", or the "tree's bark". /// ;-)
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]
