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. At the moment I'd have a "-0.2" position on things, i.e. slightly negative, as I want to get a 1.3 release out and have concerns that this might delay things, but open to persuasion & would welcome some input from someone more familiar with the core than I am who might be able to comment as to if my concerns are likely to be unfounded. /Gwyn
