struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: composable RequestProcessor
Date Wed, 04 Jun 2003 16:58:14 GMT
I'm not convinced that this configuration is Struts' responsibility.  If we 
want to define a chain of methods that will process a request we should be 
using Filters and web.xml to configure them.  Filters are the standard 
method of doing this and fit in well with our RequestProcessor (RP) methods.

All of the RP.process* methods accept a request and response object as their 
first two arguments just like Filter.doFilter().  The other args to these 
methods would need to be stored in the request and retrieved by the filter.  
So, each RP.process* method becomes a filter that performs its specialized 
task.  If you want to add Tiles or some other extension you would configure 
appropriate filters in the web.xml chain.

Why should we duplicate the effort of the container inside Struts?  
Obviously, this would be a 2.0 change so I still support the idea of making 
a RequestHandler (or some other named) interface that people can code custom 
RequestProcessors behind for 1.x.


>I still don't see why processing an "action" request is any different than 
>processing a "validation" request.
>Formed like the validation, the default request chain looks like this:
>where each of these have been defined as a Subprocessor (e.g. Validator).
>As it stands, many of the process methods take different signatures and 
>return different objects. But that could be changed so that they pass 
>around a single data transfer object with a place for all the usual objects 
>Whether each component in this sequence is systemically compatible or 
>whether the order of the processes makes sense, would be the developer's 
>responsibility, just as it is for defining a chain of Validators.
>Right now, the framework describes a lockstep lifecycle. But that really 
>isn't the framework's job. The framework should provide a pre configured 
>default lifecycle, but the developer should as much freedom as possible to 
>define whatever lifecycle works best for a given application.
>The distribution could ship with a library of Subprocessors (just as we 
>ship with a library of Validators). To use Tiles, you would make the 
>appropriate changes to the "process" property to load the Tiles 
>Subprocessors. If someone wanted to handle a different extension point 
>differently (or insert a new one), they could add a Subprocessor to the 
>library (as we can with validators), and amend the "process" property.
>So there would be no pre-ordained processABC and processXYZ methods or call 
>sequence. The processor would call each process in turn until someone cried 
>stop or the sequence was complete. You could put as many or as few 
>Subprocessors into the sequence as you liked, same as we can do with 
>A radical extension, like Tiles, may also need to subclass the main 
>"Processor" (aka the "RequestProcessor") that would call the individual 
>Subprocessors, but hopefully the methods that it overrides (like 
>internalModuleRelativeForward) won't matter to the other Subprocessors.
>Or, maybe if Tiles does not have to live within a lockstep lifecycle, there 
>might be a better way of interpolating the "processTiles" step, so that it 
>doesn't need override "internal" methods.
>So, anyway, the idea is that there would be a Subprocessor interface and 
>concrete implementations for each of the existing process methods (as 
>individual classes). The existing RequestProcessor(s) could implement a 
>Processor interface. The new ProcessManager could also implement the 
>Processor interface but call individual Subprocessors from within the 
>process method. (You might be even be able to do a concept test with a 
>RequestProcessor subclass that called inner classes based on the existing 
>processes.) Which Subprocessors the ProcessManager calls in what order 
>would be configurable.
>While not as simple as what we have now, it would be more extensible, and 
>has the virtue of using the same implementation pattern as another Struts 
>component, the Validator. Which also means that ProcessManager would not be 
>any more difficult for developers to configure and use than the Validator.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Tired of spam? Get advanced junk mail protection with MSN 8.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message