imo 1) sounds good for now; it'll at least patch it. We can look at the perfect solutation at a later time/ version.
Eelco 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 > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
