Could be, except if it's not something anyone really wants, we should probably just skip it! The whole question arose simply because one of my colleagues wanted to provide special processing for just processActionForm() and she didn't want to make the decision between extending RequestProcessor or TilesRequestProcessor.
That lead to the current discussion, which is mostly theoretical, since no one who has spent longer extending RequestProcessor is clamoring for this kind of complexity. Even if they were clamoring, no one would probably pay attention unless they put up some code to back up the clamor.
I don't think the discussion is theoretical, since you immediately stumble across this issue, when you want to implement a generic extension like the Struts Workflow Extension: It subclasses RequestProcessor. But it also needs to subclass TilesWorkflowRequestProcessor to allow people who want to use Tiles to use the workflow extension.
What if the creator of the next extension decides that his extension should work together with Tiles, the Struts Workflow Extension and without them? He needs to build subclasses of RequestProcessor, TilesRequestProcessor, TilesWorkflowRequestProcessor, and WorkflowRequestProcessor.
The one who writes the next extension has even more bad luck...
At this point, I think the main goal is to come up with a decent name for an interface which RequestProcessor could implement, or to put it off until 2.0 when we might reasonably use the name "RequestProcessor" for an interface and not be worried about compatibility with 1.x code.
It is not only a matter of providing a request processor interface, because it does not solve the problem I explained above: The number of request processor instances grows with each extension that wants to cooperate with other extensions.
We need to come up with a design that is more flexible.
--- Matthias
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
