> -----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]
