On Fri, 15 Aug 2003, Greg Reddin wrote: > Date: Fri, 15 Aug 2003 08:16:23 -0500 > From: Greg Reddin <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Developers List <[EMAIL PROTECTED]> > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
