You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martin Dietze <di...@fh-wedel.de> on 2013/03/08 23:04:13 UTC
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~down&rubrik=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~down&action=new&variant=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=new&variant=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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 6: AjaxFormComponentUpdatingBehavior on dropdown leads
to page reload
Posted by Martin Dietze <di...@fh-wedel.de>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket 6: AjaxFormComponentUpdatingBehavior on dropdown leads to
page reload
Posted by Bernard <bh...@gmail.com>.
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~down&rubrik=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~down&action=new&variant=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=new&variant=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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org