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, FM" <Pe...@rbos.com> on 2003/08/13 10:50:18 UTC
Struts Composable Request Process (was RE: ActionForwards, et al)
> -----Original Message-----
> From: Peter A. Pilgrim [mailto:peterp@xenonsoft.demon.co.uk]
--//--
>
> Craig R. McClanahan wrote:
> > On Tue, 12 Aug 2003, Peter A. Pilgrim wrote:
> >
> >
> >>So we could have convenience methods such as
> >>
> >>StrutsWebContext scontext = (StrutsWebContext)context;
> >>// Where ``StrutsWebContext'' is a type of ``ServletWebContext''
> >>
> >>ActionForm form = scontext.getActionForm();
> >>ActionMapping mapping = scontext.getActionMapping();
> >
> >
> > If we're talking about a Struts2 world (where we're willing
> to reconsider
> > the calling sequence of an Action anyway), wouldn't it be
> better to make
> > StrutsWebContext just extend WebContext instead of
> ServletWebContext?
> > That way we could have transparent support for servlets and
> portlets.
> >
> So instead you would make convenience method from WebContext instead
> I see the `WebContext.getRequestScope()' returns a mutable map of
> attribute values. In other words they are derived from
> `ServletRequest.getAttributeNames()'.
>
> But looking at the current Struts 1.1 library would you for
> compatibility
> reason also supply the `HttpServletRequest' object to Struts users?
>
> HttpServletRequest = StrutsWebContext.getRequest(); //
> convenience method
>
> and like wise `HttpServletResponse' object?
>
> >
> >>>Another import idea is that, if we wanted, we could also
> add other other
> >>>convenience methods to the context without breaking the signature.
> >>>
> >>
> My question above.
>
> >>And presumably we [as application developer] will be able
> to subclass
> >>the ServletWebContext and add application features like
> Single Sign-On
> >>/ Security / personalisation etcetera. We will be able to configure
> >>Struts Module to use our custom `Context' instead of the Struts
> >>default context.
> >>
> >>Yep this is looking sexy.
> >>
> >>
> >
> >
> > Yep ... lots of interesting room for playing around here.
> To say nothing
> > of the fact that you can compose your own request processor
> pipeline to
> > boot.
> >
>
> Moving swiftly back to the original design reason. The [old]
> request processor
> is now effectively a `Chain' isn't it?
>
> ( ... I will now continue this note at work )
>
> --
> Peter Pilgrim
> __ _____ _____ _____
> / //__ // ___// ___/ + Serverside Java
> / /___/ // /__ / /__ + Struts
> / // ___// ___// ___/ + Expresso Committer
> __/ // /__ / /__ / /__ + Independent Contractor
> /___//____//____//____/ + Intrinsic Motivation
> On Line Resume
> ||
> \\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
>
In the excitment I got caught up the discussion about customised
action forward, whereas the original design intention got chucked
to the side, namely a ``composable request processor''. So let
me spend some time discussing this:
Now I am at work. I said `RequestProcessor' currently could be
rewritten as a `Chain', because it aggregates a many `Command's.
But I am wondering about that statement. It would be seem
to me `RequestProcessor' is a very complex `Command'
Going back to the original "Decomposable request Processor" thread
there were at least two concerns:
1) How delegate or nest processors so that they do the right thing.
2) Deciding which methods of the current processor should be decomposed.
3) Configuring the chain of processor from XML.
Delegation: I believe would be like Servlet Filters as they are implemented
now. If we have servlet filters A and B , then we know that if filter A
chained to filter B. The final effect is not necessarily equal to B
followed A.
Methods: In the current request processor there is one method
`process()' which has a default implementation:
public void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
This method calls other ``process*'' methods.
processLocale(request, response);
...
processPreprocess(request, response);
ActionMapping mapping = processMapping(request, response, path);
...
ActionForm form = processActionForm(request, response, mapping);
processPopulate(request, response, form, mapping);
...
Action action = processActionCreate(request, response, mapping);
...
ActionForward forward =
processActionPerform(request, response,
action, form, mapping);
My question is if we make `RequestProcessor' a common-chain `Command'
then do then in turn make it call other `Command' in order to emulate
all the `process*()' calls. For example
// RequestProcessor implemented as complex `Command'
// Assuming we get a web context from somewhere,
StrutWebContext sc = ... ;
processPreprocessCommand.execute( sc );
...
ActionForm form = (Action)
processActionCreate.getAttributes().get("ActionForm");
...
processActionCreate.execute( sc );
Action action = (Action)
processActionCreate.getAttributes().get("Action");
...
processActionCreate.execute( sc );
ActionForward forward = (Action)
processActionCreate.getAttributes().get("ActionForward");
Is this anything like what you had in mind, Craig? Because it
looks to me a bit untidy, but the request processor has effectively
been decomposed into commands.
The problem for me is building the new request processor, complex
command. what would the API look like?
DefaultComplexProcessor dcp = ... ; // Our new request processor
Suppose I want to intercept the process of creating a new ``Action''
instance. If we write accessor method to expose the ``Chain'' that
is responsibe for creating an action, such as this:
Chain oneChain =dcp.getProcessActionCreateChain();
then I could add my custom interceptor
oneChain.addCommand( new ExpressoProcessActionCreateCommand() );
Is this speculation or truth? Am I on the right track or do you
have something else in mind.
Thoughts
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************************
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
Visit our website at http://www.rbs.co.uk/CBFM/
***********************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et
al)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 15 Aug 2003, Greg Reddin wrote:
> Date: Fri, 15 Aug 2003 08:16:23 -0500
> From: Greg Reddin <gr...@fnf.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> greg.reddin@fnf.com
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Struts Composable Request Process (was RE: ActionForwards,
> et al)
>
> > If we were to build everything on such a structure, configuring a Struts
> > app would be mostly done by letting Struts load its standard definitions
> > of all the chains (from some internal-to-Struts XML resource), then
> > letting the application load its own config files -- possibly overriding
> > the standard chain definitions -- then specifying the name of the chain
> > that initially gets control (and is therefore responsible for processing
> > the entire request). There wouldn't really be a RequestProcessor any more
> > (although for 1.1 we'd probably implement all this inside a new one that
> > simply replaces the process() method with the appropriate chain lookup and
> > execution.)
> >
>
> Regarding the 1.1 request processor, do you envision the process()
> method just reading the XML file and calling execute() on a chain, or
> would you expect to have several predefined chains that process() would
> execute and application developers could extend? From your notes above,
> it looks like the process() method would just execute one or more
> chains. Peter's code in this thread sort of looked like it would invoke
> each processX() method as a separate chain.
>
> I guess the question is "How composable should it be?" Obviously, there
> are some things that *have* to be done for it to really be a Struts
> request processor, right? We may not want applications to be able to
> compose those things out. And, as you mentioned earlier, order is
> definitely important.
>
My inclination would be that Struts itself would load the entire
definition of the standard pipeline (or pipelines -- no reason to have
only one; it should be able to map module-relative URLs) out of an
internal configuration file. There would be standard plugin points where
users could optionally install additional "phases" by simply defining a
Chain in the Catalog with a particular name (the example in
contrib/struts-chain does this for a preprocess action) so that casual
users are not tempted to muck with the core definitions. For advanced
users, simply replace the entire standard pipeline with something to your
liking.
After all, nothing stops a 1.1 user from overriding the process() method
in RequestProcessor and totally ignoring the existing pipeline (which is
exactly what a 1.1-based implementation of a chain processor would do :-).
It's not like we're really introducing more choices to shoot yourself in
the foot than already exist -- we're just making it easier to manage the
kinds of changes you want to make.
> Greg
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et al)
Posted by Greg Reddin <gr...@fnf.com>.
Yeah, I was actually thinking 1.x when I read and wrote 1.1 :-)
Thanks for clarifying.
Ted Husted wrote:
> >> (although for 1.1 we'd probably implement all this inside a new one
> >> that simply replaces the process() method with the appropriate chain
> >> lookup and execution.)
>
> For clarity, we probably should be saying the 1.x processor, since we'd
> certainly be past 1.1.x before anything like this shipped. (Old habits
> die hard.)
>
> -Ted.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
> DISCLAIMER:
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential and privileged information. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not
> the intended recipient, please contact the sender by reply email and
> destroy all copies of the original message and attachments.
>
>
DISCLAIMER:
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et
al)
Posted by Ted Husted <hu...@apache.org>.
>> (although for 1.1 we'd probably implement all this inside a new one
>> that simply replaces the process() method with the appropriate chain
>> lookup and execution.)
For clarity, we probably should be saying the 1.x processor, since we'd
certainly be past 1.1.x before anything like this shipped. (Old habits
die hard.)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et al)
Posted by Greg Reddin <gr...@fnf.com>.
> If we were to build everything on such a structure, configuring a Struts
> app would be mostly done by letting Struts load its standard definitions
> of all the chains (from some internal-to-Struts XML resource), then
> letting the application load its own config files -- possibly overriding
> the standard chain definitions -- then specifying the name of the chain
> that initially gets control (and is therefore responsible for processing
> the entire request). There wouldn't really be a RequestProcessor any more
> (although for 1.1 we'd probably implement all this inside a new one that
> simply replaces the process() method with the appropriate chain lookup and
> execution.)
>
Regarding the 1.1 request processor, do you envision the process()
method just reading the XML file and calling execute() on a chain, or
would you expect to have several predefined chains that process() would
execute and application developers could extend? From your notes above,
it looks like the process() method would just execute one or more
chains. Peter's code in this thread sort of looked like it would invoke
each processX() method as a separate chain.
I guess the question is "How composable should it be?" Obviously, there
are some things that *have* to be done for it to really be a Struts
request processor, right? We may not want applications to be able to
compose those things out. And, as you mentioned earlier, order is
definitely important.
Greg
DISCLAIMER:
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Struts 2 planning and discussions
Posted by Chris Gerrard <ch...@gerrard.net>.
Hi all,
Are there any plans to have organized discussions about the thinking
towards Struts 2? WIll it happen on this list, or will there be a Wiki or
something else?
I've been an avid follower of the discussions here, admit that many of them
are beyond me, but would like to help out however I can as the
opportunities arise, even if it's something as mundane as trying to distill
out the various ideas people have had regarding how Struts should be in the
future.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
"pre"-development ?
Posted by Reinhard <un...@public-files.de>.
Hello to all,
I realized the big potential of tiles for creating clean portal-systems, but
IMHO the tiles system could be a bit more flexible.
So - I worked out a "quickhack"-extension to manipulate TilesDefinitions.
But - from my opinion - it was just the first step.
Now I have more ideas, on how to make tiles more flexible.
Is this the right place, to talk about thus ideas?
Is there already an ongoing development?
Is it ok, if I would like to help?
cheers Reinhard
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et al)
Posted by Greg Reddin <gr...@fnf.com>.
> I was mainly trying to be sure that it was technically feasible to use
> commos-chain for this kind of decomposition, and that seems to be the
> case. For actually implementing a 1.1-compatible layer, we'd need more
> than just me working on the code. But I wanted to share my initial
> progress to see if it caught anyone else's interest.
I am very interested in this. So far we've avoided extending Request
Processor because it's not currently composable. Some of our apps might
need Tiles, while others might not. So anything we do to RP, we'd have
to do at least twice -- one to extend TilesRequestProcessor and one to
extend standard Request Processor. But, we have several extensions that
really belong in a request processor more than a "base action". So
count me in as an interested party who's willing to help.
Greg
DISCLAIMER:
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et
al)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 13 Aug 2003, Greg Reddin wrote:
> Date: Wed, 13 Aug 2003 11:54:01 -0500
> From: Greg Reddin <gr...@fnf.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> greg.reddin@fnf.com
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Struts Composable Request Process (was RE: ActionForwards,
> et al)
>
> > Not only "had in mind" but "already partly done". There would no longer
> > be any direct calls to each "process" method -- instead, they would all be
> > commands in a chain that is preconfigured by Struts (and then optionally
> > specialized by the app developer).
>
> So is this already partialy implemented in a component that you haven't
> checked in yet? I see the configuration file that outlines all the
> commands and I see the commands, but I don't see the piece that would be
> the equivalent to today's request processor -- the piece that will
> invoke the chain.
>
> Did I miss something?
>
No, you didn't miss anything ... that's why I said it was *partly* done
:-).
I was mainly trying to be sure that it was technically feasible to use
commos-chain for this kind of decomposition, and that seems to be the
case. For actually implementing a 1.1-compatible layer, we'd need more
than just me working on the code. But I wanted to share my initial
progress to see if it caught anyone else's interest.
> Greg
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et al)
Posted by Greg Reddin <gr...@fnf.com>.
> Not only "had in mind" but "already partly done". There would no longer
> be any direct calls to each "process" method -- instead, they would all be
> commands in a chain that is preconfigured by Struts (and then optionally
> specialized by the app developer).
So is this already partialy implemented in a component that you haven't
checked in yet? I see the configuration file that outlines all the
commands and I see the commands, but I don't see the piece that would be
the equivalent to today's request processor -- the piece that will
invoke the chain.
Did I miss something?
Greg
DISCLAIMER:
This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and attachments.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Struts Composable Request Process (was RE: ActionForwards, et
al)
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 13 Aug 2003, PILGRIM, Peter, FM wrote:
> In the excitment I got caught up the discussion about customised
> action forward, whereas the original design intention got chucked
> to the side, namely a ``composable request processor''. So let
> me spend some time discussing this:
>
> Now I am at work. I said `RequestProcessor' currently could be
> rewritten as a `Chain', because it aggregates a many `Command's.
> But I am wondering about that statement. It would be seem
> to me `RequestProcessor' is a very complex `Command'
>
> Going back to the original "Decomposable request Processor" thread
> there were at least two concerns:
>
> 1) How delegate or nest processors so that they do the right thing.
>
In contrib/struts-chain you'll see one approach for doing that. I
separated the chain to pick which module to run from the chain to run the
standard processing pipeline. In commons-chain there's a generic lookup
command so that you can easily call nested chains by literal names or
indirectly (by computing the name of the chain you want and then looking
it up in the Catalog).
There's also an option on the lookup command to ignore lookup failures.
The example config uses this to let you optionally plug a preprocess
command into either of the above two chains, simply by registering your
own command under a particular name.
> 2) Deciding which methods of the current processor should be decomposed.
>
If we're trying to emulate the 1.1 RequestProcessor, wouldn't it need to
be all of them? That's what I started down the path of doing.
> 3) Configuring the chain of processor from XML.
>
commons-chain has some utilities to easily construct a Digester instance
that can parse them, and contrib/struts-chain uses that. See the
following file in the Struts sources:
contrib/struts-chain/src/conf/chain-config.xml
There are, of course, no restrictions on how you actually register things
in the Catalog, so you can load chain definitions from a database (or
whatever) as well.
>
> Delegation: I believe would be like Servlet Filters as they are implemented
> now. If we have servlet filters A and B , then we know that if filter A
> chained to filter B. The final effect is not necessarily equal to B
> followed A.
>
Order is definitely important in the standard chain, just like it is
today.
> Methods: In the current request processor there is one method
> `process()' which has a default implementation:
>
> public void process(HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException
>
> This method calls other ``process*'' methods.
>
> processLocale(request, response);
>
> ...
>
> processPreprocess(request, response);
>
> ActionMapping mapping = processMapping(request, response, path);
>
> ...
>
> ActionForm form = processActionForm(request, response, mapping);
> processPopulate(request, response, form, mapping);
>
> ...
>
> Action action = processActionCreate(request, response, mapping);
>
> ...
> ActionForward forward =
> processActionPerform(request, response,
> action, form, mapping);
>
> My question is if we make `RequestProcessor' a common-chain `Command'
> then do then in turn make it call other `Command' in order to emulate
> all the `process*()' calls. For example
>
> // RequestProcessor implemented as complex `Command'
> // Assuming we get a web context from somewhere,
> StrutWebContext sc = ... ;
>
> processPreprocessCommand.execute( sc );
>
> ...
>
> ActionForm form = (Action)
> processActionCreate.getAttributes().get("ActionForm");
>
> ...
>
> processActionCreate.execute( sc );
> Action action = (Action)
> processActionCreate.getAttributes().get("Action");
>
> ...
>
> processActionCreate.execute( sc );
> ActionForward forward = (Action)
> processActionCreate.getAttributes().get("ActionForward");
>
>
> Is this anything like what you had in mind, Craig? Because it
> looks to me a bit untidy, but the request processor has effectively
> been decomposed into commands.
>
Not only "had in mind" but "already partly done". There would no longer
be any direct calls to each "process" method -- instead, they would all be
commands in a chain that is preconfigured by Struts (and then optionally
specialized by the app developer).
See the sources in contrib/struts-chain.
> The problem for me is building the new request processor, complex
> command. what would the API look like?
>
> DefaultComplexProcessor dcp = ... ; // Our new request processor
>
> Suppose I want to intercept the process of creating a new ``Action''
> instance. If we write accessor method to expose the ``Chain'' that
> is responsibe for creating an action, such as this:
>
> Chain oneChain =dcp.getProcessActionCreateChain();
>
> then I could add my custom interceptor
>
> oneChain.addCommand( new ExpressoProcessActionCreateCommand() );
>
> Is this speculation or truth? Am I on the right track or do you
> have something else in mind.
>
At the API level, Chain.addCommand() is absolutely the way that chains are
actually constructed. It's easier to build them from XML or some other
data source, though.
If we were to build everything on such a structure, configuring a Struts
app would be mostly done by letting Struts load its standard definitions
of all the chains (from some internal-to-Struts XML resource), then
letting the application load its own config files -- possibly overriding
the standard chain definitions -- then specifying the name of the chain
that initially gets control (and is therefore responsible for processing
the entire request). There wouldn't really be a RequestProcessor any more
(although for 1.1 we'd probably implement all this inside a new one that
simply replaces the process() method with the appropriate chain lookup and
execution.)
> Thoughts
>
> --
> Peter Pilgrim,
> Struts/J2EE Consultant, RBoS FM, Risk IT
> Tel: +44 (0)207-375-4923
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org