> -----Original Message----- > From: BaTien Duong [mailto:[EMAIL PROTECTED] == > > 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. >
Chain of Responsibility is pattern that separates the sending of a message from the receiver of message. So it solves different problem for inverse of control. I think you are looking at this from the perspective of `callback interfaces', therefore IoC appears to have much more power and depth. > 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. > IoC is an application level, because it does help with configuration and look up of services, beans or other artefacts. The CoR is a messaging pattern primarily. It is not a question of either CoR or IoC, you can use both of them together. The question is how? That is question of architecture, what is the best way to build a house, I think you will find a million and one answers there. There are ways of designing software, but one needs to understand what the patterns are, what are they purporting to solve. After that it is easier to decide if a particular pattern is heavy or lightweight, better or worse, because each pattern has it original context of application. hth > 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. An IoC container can take over construction of objects that you required a lightweight container full stop (period). If you want to take advantage of AOP light weight containers then you must register your objects with the IoC container beforehand. > 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. I think Struts is a FrontController. So I'd be more inclined to let Struts be Struts. There appears to be confusion about CoR and IoC and also various idioms and patterns common place in the J2EE world. In the new Struts applications I think there are three chains: front controller, action, and view. The chain of the front controller effectively ties together the CoR for the request processor. The other two chains are for Web User Interface "actions" and "view" rendering technologies. I think the latter two chains are well understood, but the "front controller" chain is not at the moment, at least by me. The original idea of commons chain was to solve the request processor implementation debacle. If I have subclass `TilesRequestProcessor' with a class `MySpecialRequestProcessor', there was no way I could also make it a subclass of another implementation ie `WorkflowRequestProcessor'. The theory is to compose your own request processor, but has anyone got a working example of such a beastie (yet)? ==////== -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, 10 South Colonnade, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 ============================================================================== This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. ============================================================================== --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
