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.
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?
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]
