On Tue, 27 Aug 2002, Christopher Seekamp wrote:
> Date: Tue, 27 Aug 2002 12:52:55 -0400
> From: Christopher Seekamp <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Multiple RequestProcessors
>
>
>
>
>
>
> Craig:
>
> That sounds reasonable to me. I have no problem adding what we have to the
> contrib folder. From looking around at the doc on submitting patches etc.
> I only understand how you submit a patch for an existing file. I don't
> want to trouble you for a lot of details, so can you point me to something
> that explains how you submit a patch that contains new folders
> (directories) and new files. I guess I can't use diff for new files and
> folders.
>
Sorry for the lack of docco on this. The simplest way for an initial
hierarchy like this would be to submit a zip file that contains the entire
new set of files, with a note that says something like "please unzip these
files into a new "contrib/foo" directory in the CVS server. You could put
this in as an enhancement request in Bugzilla
<http://nagoya.apache.org/bugzilla/> with a file attachment.
After the initial checkin, patches would work like they do for any other
existing file.
> Thanks.
>
> Chris Seekamp
>
Craig
>
>
> Hi Chris,
>
> Thanks for the thoughtful analysis on this topic! Refactoring
> RequestProcessor in a manner that lets you combine customizations (like
> your suggestion to use a decorator pattern) is high on my list of things
> to look at for a post-1.1 release of Struts. I don't know of anyone who
> has proposed a comprehensive suggested design for this yet (and I've
> purposely avoided starting the design discussions lest they distract us
> from getting 1.1 out the door ... :-).
>
> In the mean time, it would definitely be worth exploring whether we could
> create a DecoratableRequestProcessor (or whatever we want to call it) as
> an optional replacement for the current one, implementing your decorators
> or chaining inside that implementation -- so that ActionServlet doesn't
> know anything special is going on. We could perhaps store the
> experimental implementation in the "contrib" directory so that people
> could try it out. We could use the results to influence the final design
> of the "real" request processor for Struts post-1.1.
>
> Does that sound like a viable plan?
>
> Craig
>
>
> On Mon, 26 Aug 2002, Chris Seekamp wrote:
>
> > Date: Mon, 26 Aug 2002 16:55:58 -0400
> > From: Chris Seekamp <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > 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].
> org>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED].
> org>
> >
> >
>
>
> --
> 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]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
