> -----Original Message----- > From: Niall Pemberton [mailto:[EMAIL PROTECTED] ==////== > > I've looked at 1.3 and the Chain stuff, but not actually tried it out. > However the original RequestProcessor is still there and > presumably still > works. The default RequestProcessor is now the chain > ComposableRequestProcessor, so to use the original one would > have to be > configured. No one (to my knowledge) has said it should be removed, so > theres nothing to stop it being maintained/enhanced and if > Struts continues > to ship with both no need (IMO) for a fork. Having said that if > ComposbaleRequestProcessor does eveything the original one does and is > backwardly compatible then there probably won't be much motivation to > continue developing it. > > Niall
I thought original use-case design for the ComposableRequestProcessor is to solve the multiple inheritance problem with custom request processor. For example I might mave `ExpressoRequestProcessor' which subclasses `TilesRequestProcessor', but my framework users are be troubled if they want to use `WorkflowRequestProcessor', which is not a subclass of `TilesRequestProcessor'. In the new world, all the RequestProcessors will be rewritten as Commands/Chains. It should be simply a case of configurating all the disparate chains/commands together to invent a new style request processor. I am missing steps sorry. Each RP will rewritten with Commands: ExpressoRequestProcessor ExpressoExecuteAction command ExpressoCreateForm command ... WorkflowRequestProcessor WorkflowVerifyUser command WorkflowPopulateActionForm command WorkflowProcessAction command ... TilesRequestProcessor (NB:The above commands are made-up in my head) The each RP command will be tied up with the default Struts Core Commands (or it may even replace some or all of them!) The tricky bit is the configuration. Writing your commands must be fully documented and unit tested for each framework, of course. Such configuration will be for experts only or must clearly written up in your application user guide, because potentially the whole web application could be screwed up ... but I suppose that is the fallback of extreme flexibility. There is also a different use-case, which Ted and other has discussed, the business logic chain catalogue. > > ----- Original Message ----- > From: "Dakota Jack" <[EMAIL PROTECTED]> > Sent: Wednesday, March 16, 2005 5:52 AM > > > I do hope that if Struts v1.3 begins to tie more than the composable > > request processor to this Command/Chain business that a fork is > > allowed in Struts v1.2. Once the problems with the > Command/Chain idea > > begin to cause "hacks" that then enslave the framework to the > > Command/Chain pattern, things will become frozen rather > than fluid, in > > my opinion. > > I do not think so, because clearly you can reconfigure the chain config for the default ``ComposableRequestProcessor'' to call your own specialised Commands. Inside your custom Commands you can break into processing that you want in the Struts processing flow. All you have be is an Struts expert on what is exactly going in the CRP under the surface. Newbies Struts user will not want to or should be advised to "meddle with things you do not [fully] understand" -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, 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]