I think you are addressing a good point. Building a set of interfaces is certainly not enough. It is not enough anyway, because there must be a driving class that implements the method "process". It must instantiate the right instances of the sub request processors:
Would grouping the interfaces as I have done above actually solve this problem? If you have two request processor that implemented my `DispatchRequestProcessorInterface ' as above you would still have the same messy aggregation problems as above, albeit is lesser number of methods to consider. I am unsure if this is easier.
There is another question here, or couple.
By making a request processor an interface you pass on
the concrete details, the actual whereabouts of the data attributes and the other object instance data members to some other class X out there.
If you look at the javadoc for the default `RequestProcessor' it has a list collection of Action objects. This is a map collection of all the actions that are configured via XML for this module config. When you start delegating or aggregating request processors, you must ask the question, in which controller has the module `Actions'.
For example
class AcmeRequestProcessor extends RequestProcessor
implements RequestProcessorInterface {
RequestProcessorInterface tiles = new TilesRequestProcessor();
public void whereAreMyActions( ) {
// Which is the correct collection actions // for this module config?
this.actions.get("/Login.do" );
// or tiles.getAction().get("/Login.do" );
}
I think we have NOT been considering the data members of the
current default controller (RP).
// Check for any role required to perform this action
if (null == this.processRolesRequestProcessor) {
// create it
this.processRolesRequestProcessor = this.createProcessRolesRequestProcessor(...);
}
if (!this.processRolesRequestProcessor.processRoles(request, response, mapping, this)) {
return;
}
...
This driving request processor who selects the instances of the sub request processors should be the one who keeps the members. Every sub request processor must be allowed to modify these members. Therefore the driving request processor must pass a reference to himself to each method now (like in the above sample code). The members that are exposed (e. g. the action map) must be accessible with getter methods then.
I don't see why this should influence performance. It is just a few more function calls that does not add significant weight to the many function calls already involved to process a request.New accessor and mutators would be required, as I hinted with the ``Map getActions()'' call above.
May be this is a "separation of concerns" design. The multiple interface no longer sounds right, especially with the data members. I am starting think there could be performance
problems if we start delegating calls ad infinitum too.
--- Matthias
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
