Just add a method:
getBufferedResponse()
{
}
the default RequestCycle just returns a StringResponse
and the WebRequestCycle also returns a StringResponse but with an overwritten encode url.
How would you capture in 1 all the calles to StringResponse.encodeUrl() ??
What if code doesn't go through the encoding strategy? But calls it directly on the current response?
Also what is the original response if for example we have nesting with 2 responses
(this did happen sometimes in the redirectTo() call of WebRequestCycle where the nesting did go deeper then one buffer...
i think a factory method on RequestCycle is safer if everybody is using that when setting there own the response object in the request cycle.
(Maybe we could check this somehow? so that RC.setResponse() is checking if it is a supported response type?)
johan
On 3/31/06, Igor Vaynberg
<[EMAIL PROTECTED]> wrote:
hey guys,
matej stumbled upon a problem we have with url encoding. if the client doesnt support cookies the container uses url rewriting - but that means any url generation has to be passed through HttpServletResponse.encodeUrl ().
the encoding strategy calls RequestCycle().getResponse().encodeUrl() and this works great most of the time. but what if we replace the response? default implementation of encodeUrl() is a noop so rewriting the container needs wont work because the encodeurl() is never called on the servlet response.
i see two possible solutions:
1) make the encoding strategy always use the original response.encodeurl() - that means the response on the /bottom/ of the stack. the con is that this does not allow different requests to override encodeUrl(). pro: our non-default responses like StringResponse can keep default constructors. pro: no api break this late in the game
2) we have to change all our response objects to always take in the original response so encodeUrl() can be chained all the way down to the original response. con: messier api con: api break
what do you guys think?
-Igor
