Re: Wicket 6: AjaxFormComponentUpdatingBehavior on dropdown leads to page reload
On Sat, March 09, 2013, Bernard wrote: I would try to debug the constructor of the page and/or override and debug life cycle methods of the page and then work up the call stack why they are executed. Thank you for your reply. Having slept a night over it I found the problem. Like a couple of times before, whenever it comes to request handling in a Wicket 1.5+ system, debugging mapRequest() in CompountRequestMapper is extremely helpful for understanding how your system works :) In my case one from a number of custom page mappers in my system (most of which derive from or wrap a MountedMapper) was the culprit. After doing some magic on the request, in mapRequest() it just returned a RenderPageRequestHandler instead of passing the request on to super.mapRequest(). I actually like the RequestMappers introduced in 1.5, but being so powerful they also exhibit plenty of ways to shoot yourself into the foot and produce rather bizarre effects.. Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= In an organization, each person rises to the level of his own incompetency. -- The Peter Principle - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 6: AjaxFormComponentUpdatingBehavior on dropdown leads to page reload
I've just spent several hours trying to debug a rather strange effect with a dropdown and a AjaxFormComponentUpdatingBehavior. I have a component which is used in several places of the system. It contains a dropdown to which a AjaxFormComponentUpdatingBehavior is added. Whenever the user selects a value, a label is displayed underneath. This component has been in use in different parts of the system for quite some time now. After having upgraded to Wicket 6.6, it does no longer work - on one particular page. While on all other pages it works just fine, on that particular page every time I change something, the page reloads (just as if I had attached an AjaxFormSubmitBehavior (which of course I had not, actually there is not a single one used within the whole project). When doing this reloading, my AjaxFormSubmitBehavior's handler is never invoked. I checked the requests the browser gets to see, and it seems like there isn't any difference. Just in case, here's roughly what I get on the pages where it works: Path: http://localhost:8080/editor/editorial-tools/rundschreiben?7-1.IBehaviorListener.1-page~body-stage-stage_content-wrapped_content-content-editor-form-object_editor-groups-0-group-attributes-7-item-value-choice-ajax~holder-drop~downrubrik=Rundschreiben Method: POST The next request is an icon for the stuff displayed later. On the bad page, the request does not look too much different (it's just a different page): Path: http://localhost:8080/foo/bar/nav/foobar-xxx?14-1.IBehaviorListener.1-page~body-stage-stage_content-wrapped_content-foo~content-choice-ajax~holder-drop~downaction=newvariant=foo-sub-page Method: POST Only after it, I get the original path, but a redirect: : Path: http://localhost:8080/foo/bar/nav/foobar-xxx?action=newvariant=foo-sub-page Method: GET Status Text: 302 (Moved Temporarily) Now this indicates that something's going wrong in the Java code rather than in Javascript. I tried to find the point where the multiplexing is done and from where the Ajax behaviours are invoked, but I did not find it. Now I feel really clueless. Is there a wellknown Gotcha which simply I don't know of? Maybe anybody had the same problem before? Or, at least, where should I step into the Wicket code in order to find out where it goes wrong? Any help appreciated! Cheers, M'bert -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Dann freuen wir uns und gehen weiter und denken noch im Kuessegeben: Wie nah sind uns manche Tote, wie tot sind uns manche, die leben. -- Wolf Biermann - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 6: AjaxFormComponentUpdatingBehavior on dropdown leads to page reload
Hi, I would try to debug the constructor of the page and/or override and debug life cycle methods of the page and then work up the call stack why they are executed. As an example (not necessarily applicable in your case), one could find this way that the page had expired and Wicket just reconstructed it which could be surprising. See ListenerInterfaceRequestHandler#respond(). Regards Bernard On Fri, 8 Mar 2013 23:04:13 +0100, you wrote: I've just spent several hours trying to debug a rather strange effect with a dropdown and a AjaxFormComponentUpdatingBehavior. I have a component which is used in several places of the system. It contains a dropdown to which a AjaxFormComponentUpdatingBehavior is added. Whenever the user selects a value, a label is displayed underneath. This component has been in use in different parts of the system for quite some time now. After having upgraded to Wicket 6.6, it does no longer work - on one particular page. While on all other pages it works just fine, on that particular page every time I change something, the page reloads (just as if I had attached an AjaxFormSubmitBehavior (which of course I had not, actually there is not a single one used within the whole project). When doing this reloading, my AjaxFormSubmitBehavior's handler is never invoked. I checked the requests the browser gets to see, and it seems like there isn't any difference. Just in case, here's roughly what I get on the pages where it works: Path: http://localhost:8080/editor/editorial-tools/rundschreiben?7-1.IBehaviorListener.1-page~body-stage-stage_content-wrapped_content-content-editor-form-object_editor-groups-0-group-attributes-7-item-value-choice-ajax~holder-drop~downrubrik=Rundschreiben Method: POST The next request is an icon for the stuff displayed later. On the bad page, the request does not look too much different (it's just a different page): Path: http://localhost:8080/foo/bar/nav/foobar-xxx?14-1.IBehaviorListener.1-page~body-stage-stage_content-wrapped_content-foo~content-choice-ajax~holder-drop~downaction=newvariant=foo-sub-page Method: POST Only after it, I get the original path, but a redirect: : Path: http://localhost:8080/foo/bar/nav/foobar-xxx?action=newvariant=foo-sub-page Method: GET Status Text: 302 (Moved Temporarily) Now this indicates that something's going wrong in the Java code rather than in Javascript. I tried to find the point where the multiplexing is done and from where the Ajax behaviours are invoked, but I did not find it. Now I feel really clueless. Is there a wellknown Gotcha which simply I don't know of? Maybe anybody had the same problem before? Or, at least, where should I step into the Wicket code in order to find out where it goes wrong? Any help appreciated! Cheers, M'bert - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
