Sorry I'm a bit late to the party... It strikes me that what you describe has some interesting similarities to the Struts Action Plugin Extension that was described recently:
http://marc.theaimsgroup.com/?l=struts-dev&m=102933179909461&w=2 It looks like both of these approaches will have useful input into an eventual post-1.1 solution. -- Martin Cooper > -----Original Message----- > From: Chris Seekamp [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 1:56 PM > To: [EMAIL PROTECTED] > Subject: Multiple RequestProcessors > > > Although the change in Struts 1.1 to implement the RequestProcessor > was a great improvement over having to extend the ActionServlet, > as has been pointed out before, there can be issues when multiple > people want to extend the RequestProcessor. For instance, my group > extended the RequestProcessor so Struts would work well in our > particular environment. Suppose we or our users want to > utilize Tiles, > which has some really great capabilities? Well, if we could > extend the > Tiles RequestProcessor we would now need another version of our > RequestProcessor that extended the Tiles RequestProcessor rather than > the base RequestProcessor. But in our case, we override doForward too > (like Tiles does) and we would actually need Tiles to sit on top of > (subclass) our RequestProcessor rather than the other way > around. So we > would have to take the Tiles source and generate another subclass of > the TilesRequestProcessor that extended our RequestProcessor rather > than the plain RequestProcessor. > > And as more and more extensions become available, ideally we > would like > to be able to choose various combinations of extensions to use. Of > course, using subclassing this becomes rather problematic for obvious > reasons. If there are 3 different extensions you want to > build upon, if > you are lucky you could just create three different versions of your > own RequestProcessor subclassing each of the those 3 separately. Of > course, if you want to build on two at the same time..... > Well, you get > the idea. > > So, we, and we expect others, would like to improve the chances that > our various extensions can be used together. We have implemented an > approach based on the Decorator (Wrapper) pattern that allows > processors to be chained together. If you choose not to subclass from > this wrapper class things are the same. But if you make your > RequestProcessor subclass from the wrapper and follow some simple > steps, you can be part of an ordered chain of RequestProcessor > instances. In addition to adding the wrapper, we had to make small > changes to ActionServlet in getRequestProcessor (to build the > chain the > first time it is called) and the RequestProcessor itself to call the > top (last) processor's methods and ControllerConfig to keep the > chain of classes. Besides subclassing the wrapper class > rather than the RequestProcessor, the only new things processors need > to worry about is making sure to all the subclass version of > the method > they are extending and to call the top processors version's of other > processor methods they call. For example, if you have your own > processActionForward method you should remember to > call super.processActionForward. You normally would want to do this > anyway. Continuing the example if processActionForward wants to call > doForward, it should call the top processors doForward instead because > it might not be the top (last) processor in the chain. > > We know others have brought up the problem of multiple > RequestProcessors before. We would be happy to donate our approach as > a starting point, because we would like different extensions that > require extensions to RequestProcessor to be usable together > as much as > possible without having to compile numerous different versions. For > example, using the straight inheritance approach we would have to be > prepared to generate a new version of the Tiles RequestProcessor > extending our RequestProcessor every time there was a change made in > the Tiles RequestProcessor. So maybe there are some > far-reaching plans > to address this issue in Struts or maybe someone else is already > working on a different solution? > > If not, is there any interest in discussing extending the > RequestProcessor support to support some kind of chaining approach? I > would be happy to give more details on what we have come up with. I > haven't submitted any patches yet, but I assume this is not > the kind of > thing one should simply submit as a patch anyway, at least not without > discussing the appropriateness of the approach first. > > Thanks and sorry for the long post. > > Chris Seekamp > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
