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.
Right, but I have to define two classes to accomplish this. One class without tiles support:
MyRequestProcessor implements RequestHandler
{
public processActionCreate() {
defaultRP.processActionCreate();
} public processFormCreate() {
myRP.processFormCreate();
}
...
}and one with tiles support.
MyRequestProcessorWithTilesSupport implements RequestHandler
{
public processActionCreate() {
tilesRP.processActionCreate();
} public processFormCreate() {
myRP.processFormCreate();
}
...
}If the list of extension grows (Tiles, Worklfow Extension, Expresso, ...) the number grows exponentially. You need to implement a class for each possible combination of extensions:
1. your extension alone 2. your extension + tiles 3. your extension + workflow 4. your extension + tiles + workflow 5. your extension + expresso 6. your extension + expresso + tiles 7. your extension + expresso + workflow 8. your extension + expresso + tiles + workflow
...
I agree, that a filter-like approach will not the the right way. I am just wondering whether work can be reduced by making composition more configurable. I think it is necessary to split up the request processor into mulitple classes (one that generates the action instance, one that instantiates the form, ...). Then parts of it can be replaced more selectively. That's what Jeff Robertson is talking about and it sounds good to me.
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.
--- Matthias
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
