<snip> 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. </snip>
This way of having the driving RequestProcessor be the one that implements process() and calls the other is probably the best way to go IMHO. The driving request processor will also itself implement all the various interfaces, and in the absence of a SubRequestProcessor implementing processXXX the RequestProcessor would call itself for processXXX. (Do we aditionally want certain SubRequestProcessors to provide support for a chain of implementors? ) btw: Since the processXXX implementation classes for those overridden parts are instantiated at startup, rather then having the RequestProcessor pass a reference to itself each time it calls a SubRequestProcessor we could perhaps set the reference at instantiation time in each SubRequestProcessor, or are there drawbacks to this that I havent spotted? -----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 17:48 To: Struts Developers List Subject: Re: composable RequestProcessor > > >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). > > 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: // 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. >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. > > 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. --- Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
