--- Matthias
Ted Husted wrote:
Personally, as soon as 1.1 ships, I'd like first to get out a clean release of Struts that resolves the existing deprecations, and call that 1.2. After that, IMHO, we could continue with changes to the underlying architecture.
In the 1.x series, we could do something like declare a RequestProcessorInterface, have the existing concrete classes implement that, and then change the underlying code to use interface instead, and avoid any external API changes.
I'd suggest entering an enhancement ticket, with a link to Joe's wikiPage, to keep this matter on the TODO list.
There will probably be a RC2 release in the works this weekend, so this could all happen in the short-term.
-Ted.
Matthias Bauer wrote:
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
--------------------------------------------------------------------- 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]
