Yep. Having a look at the processXXX methods in the RP Id say that most arent really amenable to chaining anyhow. (One likely exception is the processPreprocess() hook, however if chaining is required for this it could perhaps be done by an implementation of its interface 'PreprocessProcessor' that has the logic to call multiple other PreprocessProcessor implementations.)
Im guessing that for the configuration flexibility we need, we will want to add more xml elements in struts-config as child elements of the controller element that can provide the necessary info, Id prefer this to just having a whole bunch of extra attribute directly hanging off the controller element. -----Original Message----- From: Matthias Bauer [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 June 2003 18:10 To: Struts Developers List Subject: Re: composable RequestProcessor > > ><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? ) > > In my opinion it is enough to go without chaining support. >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? > > I don't think there are any drawbacks. It will definitely make sense to establish the references at startup time. This is also the approach I am going in the workflow extension. --- 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]
