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(){
tilesRP.processActionCreate();
}public processFormCreate{
someOtherRP.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 Filters.
David
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" /> </manager>
... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
