struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 14:05:47 GMT
>For two extensions being around this can be accomplished. But as soon as 
>the number of extensions grows beyond 2 (which has already happened) this 
>is fairly impossible. Providing a RequestProcessor interface does not 
>really relieve the situation. Even though it will  make it easier to 
>compose a request processor from other request processors, a subclass for 
>each possible combination of request processors must be implemented.

I don't see how that's true.  You would make a class like:

MyRequestProcessor implements RequestHandler
public processActionCreate(){

public processFormCreate{

So your implementation of the interface selects whatever request processors 
it wants to use to fulfill the requests.

>Thus, by now I believe the request processor architecture should be changed 
>more fundamentally to allow a more selective change of functionality. Maybe 
>they should be working more like servlet filters, so they can be chained?

I'm against mimicing Filters because that's the container's job.  If we want 
Filter behavior then we should design the RequestProcessor as a set of 


>Any thoughts?
>--- Matthias
>Peter A. Pilgrim wrote:
>>Joe Germuska wrote:
>>>At 16:33 +0100 6/1/03, Peter A. Pilgrim wrote:
>>>>For Expresso I too have subclassed the TilesRequestProcessor
>>>>for our own ExpressoRequestProcessor. Can a module have
>>>>more than one controller?
>>>Not the way it is right now, and I'm not sure why you'd need it.  I think 
>>>if you want to use the approach you described:
>>>><manager class="ControllerManager" >
>>>>   <controller class="TilesRequestProcessor" />
>>>>   <controller class="FoobarRequestProcessor" />
>>>>   <controller class="AcmeRequestProcessor" />
>>>... then it makes more sense to define interfaces for each lifecycle 
>>>method of RequestProcessor and use the XML to configure a collection of 
>>>handlers.  But David, at least, seems to think that's overkill.  I don't 
>>>feel very strongly about it, but no one else has even weighed in.  It 
>>>would mean a lot of interfaces, given that RequestProcessor has 16 
>>>"process*" methods.  Probably it is overkill...
>>>Given the XML you provided, how would the Manager know which controller 
>>>to use when?
>>Ah ha! I thought you saying something different. Before I thought
>>ComposableRequestProcessor is not a RequestProcessor.
>>But you are saying that is. That is why my example XML is nonsense.
>>You cannot chain request processors from one to another,
>>because they were not design that way. I agree which process
>>method do you call?
>>Let's take a back step, then. What is a composable request processor?
>>What is the thing that you are trying to build?
>>MasterRequestProcessor master = new MasterRequestProcessor();
>>master.add( TilesRequestProcessor );
>>master.add( FoobarRquestProcessor );
>>Is this it?
>>Another question what is it that the different request processors
>>are override or overloading? For the Tiles controller it is the
>>init(), doForward(), processForwardConfig(),
>>internalModuleRelativeForward(), internalModuleRelativeInclude() ?
>>For Expresso controller we override
>>init(), processPreprocesss(), createAction()
>>There is a no common method here in these two controllers.
>>We cannot isolate a method that would make up a composable
>>request processor.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

The new MSN 8: smart spam protection and 2 months FREE*

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

View raw message