struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Bauer <Matthias.Ba...@livinglogic.de>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 13:26:38 GMT
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message