struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heydtmann, Dirk [ITS]" <dheyd...@sprintspectrum.com>
Subject RE: composable RequestProcessor
Date Mon, 02 Jun 2003 20:37:30 GMT
Similar problem here. For legacy reasons we have to wrap an inhouse framework around Struts
which is used by a number of application teams. Since we needed to override some RequestProcessor
method, we had to choose between TilesRequestProcessor and RequestProcessor. We picked TilesRequestProcessor,
even though most of our applications are not using Tiles. Six months ago we entered a bugzilla
ticket (#15969) asking for the TilesRequestProcessor to behave more friendly towards applications
that do not use Tiles, which has been tagged for later resolution.

Of course, it would be a better to have a generic solution to this problem, such that applications
that have no need for the Tiles feature do not have to incur the weight of the TilesRequestProcessor...

Dirk Heydtmann

-----Original Message-----
From:	Matthias Bauer [mailto:Matthias.Bauer@livinglogic.de]
Sent:	Friday, May 30, 2003 2:47
To:	Struts Developers List
Subject:	Re: composable RequestProcessor

The Struts Workflow Extension (http://www.livinglogic.de/Struts/) has 
exactly the problem you are describing. It needs to  overwrite the 
standard RequestProcessor and the TilesRequestProcessor. In order not to 
duplicate any logic, I needed to come up with a class hierarchy I am not 
100% satisified with.

Thus, I am very much in favour with a more composable RequestProcessor. 
However, I totally agree with David, that it is sufficient to provide a 
RequestProcessor interface, instead of choosing the configuration file 
approach.

But I don't see a reason why this needs to be deferred until Struts 2.0. 
Why can't the RequestProcessor interface be part of Struts 1.2?

--- Matthias




Joe Germuska wrote:

> Has anyone else wished that RequestProcessor were more composeable? 
> That is, we have come upon a case where we need to override the 
> behavior of a single method in RequestProcessor, but we feel a little 
> sketchy about closing off our ability to use other tools which 
> override RequestProcessor (like Tiles).  Technically, we could just 
> extend the TilesRequestProcessor, which works even if you aren't using 
> tiles, but that's a stop-gap.
>
> I'm sure other people have thought about how to make the 
> RequestProcessor composeable of smaller handlers for each life-cycle 
> method...    but I thought I'd see what thoughts were out there before 
> riffing on my own ideas.
>
> I "staked out" 
> http://nagoya.apache.org/wiki/apachewiki.cgi?RequestProcessor on the 
> Wiki as an alternative area for discussion, but of course, if people 
> prefer to use the mailing list, I'll be watching...
>
> Joe
>
>
>



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message