> From: Dakota Jack [mailto:[EMAIL PROTECTED]
==////==
> 
> 
> +42
> 
> 
> On Wed, 16 Mar 2005 09:23:29 +0100, Manfred Wolff
> <[EMAIL PROTECTED]> wrote:
> > Dakota Jack wrote:
> > 
> > >The idea, I thought, was to use the Commands to supplant the
> > >RequestProcessor with a composable request processor.  Some of the
> > >present suggestions are so radical as to provide some 
> question whether
> > >Struts is going to be Struts.  This is especially so of 
> the suggestion
> > >that we tie the ActionForm and the Action together.  Might as well
> > >just go to JSF and Shale?
> > >
> > >
> > I think there is on little design problem in struts that 
> depends on the
> > history: It would be much better, if Action is an interface. So you
> > would have all possibilites to use POJOs, it must only 
> implement the new
> > Action-Interface. Secondly it were also much better, when the
> > execute-Method must only take a context interface. So you have more
> > flexibility and you have no servlet-things at the paramater 
> signature:
> > 
> > public interface Action {
> >     void execute(Context context);
> > }

==////==

This is also very similar to a Commons Chain `Command' 
except that the execute() returns a `boolean' value and
the `Context' is actual a subclass of `java.util.Map';
an interface!

In Expresso Framework, we have tried a similar approach
to abstract away the HttpServlet--ness from our
web handlers.

We have simply controller, which is sort similar to the
`DispatchAction', because it demultiplexes [HTTP] request
to object method by reflection.

public abstract Controller extends org.apache.struts.action.Action {

        public  void promptForm( ControllerRequest request,
                                        ControllerRequest response )

        public  void processForm( ControllerRequest request,
                                        ControllerRequest response )

        ...
}

Where our `ControllerRequest' and `ControllerResponse' are 
abstractions. So we can in theory call our `Controllers'
from the command line e.g. outside of the container. 
Commons Chain will give you that flexibility from 
opening the box. All I am saying we are all not far
away from the Chain implementation as it exists now.

In fact there is food for thought, for us Expresso developers
if we want to refactor our `Controllers' as `Commands' in future,
but this off topic ...

It is really a design and backward compatibility issue after all.


> > 
> > where Context is also an interface.
> > 
> > I have programmed this approach by myself
> > 
> (http://plstrutsit.sourceforge.net/architecture/index.html), 
> but it were
> > quite better, if this would be integrated in struts - with backwards
> > compatibility to struts 1.1. You only need a new 
> request-processor that
> > can deal with such Action interfaces an can create such contexts.
> > 
> > Manfred
> > 
> > >If anything, I would tie the ActionForm and the Action 
> less together.
> > >
> > >I don't care what you call an Action.  I do care if it handles the
> > >request and returns an ActionForward.  If you loose that, you loose
> > >Struts altogether in my opinion.
> > >
> > >The whole command structure, remember, is only because you 
> adapted the
> > >Template Method pattern for the parts of the composable request
> > >processor requiring the Command/Chain pattern to fix its 
> difficulties.
> > > To decide for that reason that the Command/Chain structure is some
> > >pattern Valhalla is a serious error, in my opinion.

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

Reply via email to