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 15:06:41 GMT
Andrew Hill wrote:

>Well I see little point in defining an interface that simply requires you to
>implement all the hooks in the RP.
>It doesnt seem to get us any further than where we are already (well apart
>from satisfying my compulsive desires for more interfaces!)
>
>You need to break it out into multiple discrete interfaces so you can do
>something like:
>
>public class BobRequestSubprocessor implements RoleProcessor,
>ActionFormProcessor
>{
>  public void processRole(...) {
>    ...
>  }
>
>  public ActionForm processActionForm(...) {
>    ...
>  }
>}
>
>Then you can specify a class for each individual processXXX in your
>struts-config , and of course the main requestprocessor class itself which
>implements the lot and is used as a 'default' where a more specific handler
>is not specified...
>
Definitely +1, if  in the configuration each processor part can be 
specified like so:

<controller roleProcessorClass="BobRequestSubprocessor", 
formCreateProcessorClass="WhateverRequestSubprocessor", ... />


>But I still havent thought of a nice way to resolve 'conflicts'.
>For example you have the FOO and the BAR extensions written by different
>people and for the sake of example, both need to override something like
>processActionForm() ... is a generic way of handling this a possibility?
>This sort of method isnt conceptually amenable to chaining as it has to
>return a single value, and yet both extensions RPs need to do their own
>thing here. I guess that sort of method simply has to have specific code
>that is written to unite the two RPs , such as what MB has had to do to
>marry workflow and tiles under the current architecture...
>  
>
I think there are certain situations when you need to handle conflicts 
with coding. But the general problem can be relieved tremendously with 
an approach like this.

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