rethink this a little bit for 1.3/2.0
for example it might be better to have a separate ResponseOutput instead of an entire Response. things get rendered into the output. that may eliminate the need for swapping the response itself, instead swap only the output.
its feels a bit disconnected and we also /do/ want to buffer the entire reponse for redirect to buffer, not just the output. anyways, some food for thought.
-Igor
On 3/31/06,
Martijn Dashorst <[EMAIL PROTECTED]> wrote:
+1 on 1
I think it is the current best solution, suitable for 1.2. Unless we miss something that isn't possible with 1) I'd go with 1.
With the next version we can take it to the next level, and have more time to think about it.
MartijnOn 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
--
Wicket 1.2 is coming! Write Ajax applications without touching _javascript_!
-- http://wicketframework.org
