struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Husted <hus...@apache.org>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 09:54:06 GMT
Peter A. Pilgrim wrote:
 > MasterRequestProcessor master = new MasterRequestProcessor();
 > master.add( TilesRequestProcessor );
 > master.add( FoobarRquestProcessor );
 >
 > Is this it?

I would say that this is on the right track. Essentially, each of the 
process methods represent an extension point or "action". Ideally, we'd 
like to be able to load a separate handler for each extension point. The 
controller then just calls each extension point in turn.

There is also the question of whether you might need more extension 
points. Another useful approach is the one we are taking with the 
validator. We can define any number of validator objects and then chain 
them together (using the depends clause).

The request processing might work the same way as the validator 
processing. Each extension point is a processor. The request processor 
just calls a series of processors in turn, in the say way we call a 
series of validators in turn. The default series would be the one we are 
using now, but whether an application uses this set, or some other, 
would be up to the developer.

Extensions like Tiles could then be distributed as individual processors 
that can be loaded into a request sub-controller, rather than as a 
monolithic class. Of course, the default package would come with a 
predefined Tiles SubController, but a developer could pull out the 
individual processors and assemble them as needed [two from column A, 
one from column B =:0)].

-Ted.


-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message