On 9/18/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > On Tuesday, September 18, 2007, 1:14:11 PM, Ate <[EMAIL PROTECTED]> wrote: > > > b) moving AbstractAjaxBehavior.getCallbackUrl() appending > > "wicket:ignoreIfNotActive=true" to WebRequestCodingStrategy.encode(). > > This is a quite simple reordering of internal processing with > > exactly the same functionality and result as outcome, quite harmless I think > > > c) wicket-ajax Wicket.Ajax.Request.get(path) checking on query > > parameters and in that case replacing it with a Request.post(body) call > > This one I think can/should be discussed as it really does > > result in a *technically* different behavior. > > I do think in the case of Ajax requests, this really doesn't > > matter as it won't effect the browser state at all, and my solution really > > is > > most transparent one I could think of. > > But, as it also changes the behavior in a plain servlet > > environment, and as such it I could understand people would feel a bit > > uncomfortable with it. > > I already suggest in the description for this change I'm open > > to other solutions, like only doing this when running in a portlet > > environment. > > Then, this issue would become moot for the servlet environment, > > we just need to find some way to indicate the current environment > > (servlet|portlet) > > in javascript to the browser. > > > > 5) WICKET-924: non-relative urls in Ajax.Request.redirect callback handling > > Actually, I would consider proposing this change regardless of the > > discussion of portlet-support. The current hard coded expectancy an Ajax > > callback redirect > > can and may only be a Wicket relative url doesn't seem very > > flexible. For the portlet-support this change is needed though. > > And, if the redirect url *is* relative as expected in the current > > implementation, my changes won't do anything anyway. > > But if there are major objections to it, we could discuss solving > > it in a similar way as we could do with the Ajax.Request.get(path) -> > > .post(body) change. > > If we can push the current runtime environment (servlet|portlet) to > > the browser the ajax script could maintain the current behavior when > > running in a servlet. > > > I think the areas that I'm concerned about are primarily these ones, > not with respect to the specific changes themselves, but more of a > concern as to whether we should be changing the trunk right now & how > much of an impact these would have on non-portlet specific codepaths. > I guess the specific concern relates to whether we have sufficient > confidence, whether or not that's via unit test, to be happy with the > changes.
I share that concern. But the best thing we can do here is write better/ more unit tests for the URL handling. We should do that regardless of this proposal really. Eelco
