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 14:51:43 GMT
>
>
>> 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

...


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

--- 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