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]
