Re: composable RequestProcessor

[Matthias Bauer]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]