You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Pilgrim, Peter" <pe...@csfb.com> on 2005/03/17 16:51:18 UTC
RE: POJO Actions and the ActionCommand interface (Re:
Configurati on inheritance, module init code)
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
==////==
>
> 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" <da...@gmail.com>
> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: POJO Actions and the ActionCommand interface (Re: Configurati on inheritance, module init code)
Posted by Dakota Jack <da...@gmail.com>.
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
<pe...@csfb.com> wrote:
> > -----Original Message-----
> > From: Niall Pemberton [mailto:niall.pemberton@blueyonder.co.uk]
> ==////==
> >
> > 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" <da...@gmail.com>
> > 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org