Just to play around with this idea, I've attached my initial hack at a
1.x-compatible composable request processor using struts-chain. Let me
know if this is anywhere near the mark for a 1.x request processor.
Here's a few notes/questions:
1) It does not do the "servlet-complete" chain b/c in 1.x
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 probab
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
> -Original Message-
> From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED]
--//--
>
> 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;
> >>/
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
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
