a few hours before we (matej and i) had this discussion.
We tried to rename StringResponse to StringWebResponse and make it a really a WebResponse. But igor encountered
a few exceptions and other things that he reverted it again.
I also agree that a NullResponse and the StringResponse should be normal Response objects and not WebResponse objects.
But WebRequestCycle just wants those...
For example we could remove the deprication of getWebResponse() and don't cast in getResponse()
But the problem is that a user can still call getWebResponse() and get a classcast exception because we did somewhere
replace it with a null or string response. Is this a bad thing? Will this happen a lot??
I don't know.
The other solution i thought about (but still i am not really into it...) is making a IWebResponse interface..
And the WebRequestCycle does use that interface and it overrides setResponse()
When a setResponse is done with a none IWebRespone object. It will wrap it.
And pass all the Response methods to that given response object. And the IWebResponse objects can be routed to the getOriginalResponse() object.
Then it doesn't matter where the output goes to. But the rest still works maybe we could route to getOriginalResponse() but then
getHttpServletResponse() call wouldn't work (this shouldn't be called anyway but...)
Then we still have the question if a setResponse is done with a StringResponse, should all the calls like setDateHeader go to the original response or not
or are that always NOP's
What the best solution is currently.. i don't know. Maybe we should just keep the getResponse/getWebResponse as it is in 1.2 and let it be that way.
It seems to work fine in 1.2 at the moment so not having there the covariant return types is a pitty but maybe just not possible,
johan
On 7/26/06,
Matej Knopp <[EMAIL PROTECTED]> wrote:
We were hunting a bug with Johan, which turned out to be fact that
AjaxRequestTarget.EncodingResponse is derived from Response instead of
WebResponse.
WebRequestCycle.getReponse casts the response to WebResponse, which
means that all responses used in WebRequestCycle have to be
WebResponses. Does this make sense? Does it make sense to have
StringResponse, NullResponse, etc... all derived from WebResponse
instead of Response?
I don't think so. I think we should revert the deprecation of
WebRequestCycle#getWebResponse and make getResponse just return Response.
Ideas?
-Matej
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
