I think you are missing my point, Peter. Clearly you can use different commands in a chain. That is, after all, exactly what you do do.
On Thu, 17 Mar 2005 15:51:18 -0000, Pilgrim, Peter <[EMAIL PROTECTED]> wrote: > > -----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] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
