You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Bernard <bh...@gmail.com> on 2013/03/09 00:22:12 UTC

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~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


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