struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <>
Subject Re: composable RequestProcessor
Date Wed, 04 Jun 2003 11:04:54 GMT
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 (request,response,mapping,form,action,forward).

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 Validators.

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:

View raw message