struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: composable RequestProcessor
Date Fri, 30 May 2003 13:39:59 GMT
>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'm fine with changing this in 1.x but not with a name like 
RequestProcessorInterface or IRequestProcessor.  We need to think up a 
better name but we can leave that discussion for post 1.2 or post 
suggestions to the enhancement ticket.  It would also be good to change 
ExceptionHandler and the various config objects to interfaces as well but 
that may need to wait for 2.0.

David

>
>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: struts-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>>
>>
>
>
>--
>Ted Husted,
>Struts in Action <http://husted.com/struts/book.html>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


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


Mime
View raw message