struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: Multiple RequestProcessors
Date Wed, 04 Sep 2002 04:44:20 GMT
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:seekamp@us.ibm.com]
> Sent: Monday, August 26, 2002 1:56 PM
> To: struts-dev@jakarta.apache.org
> 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:struts-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:struts-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message