struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject Re: composable RequestProcessor
Date Mon, 02 Jun 2003 14:36:25 GMT
>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

You need to make a decision in your app about what technologies you will 
use.  When you add a technology you will modify the processor accordingly.  
You don't need a class for every combination, just one for the combination 
being used in your app.


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

MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message