Re: composable RequestProcessor

[David Graham]

One thing that bothers me is that RequestProcessor is not an interface which 
leads to the Tiles situation.  If it were an interface, you could implement 
your one method and delegate the rest to the TilesRequestProcessor or any 
number of other processors.

IMO, RequestProcessor should be an interface in Struts 2.0 to allow the 
composition you're looking for.

David

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



--
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
        --Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]