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 2014/02/06 10:48:01 UTC
Strange: Ajax-updates from a form inside a modal dialogue "echoed"
in the page underneath
I've just spent several hours trying to figure out what's going
wrong here without any success. I am investigating a very
strange effect:
In my application I have a search panel in which several
dropdowns are used to select search settings. Some of these
settings depend on each other, so that they have their "change"
events digested by AjaxFormComponentUpdatingBehavior.
Now on a particular page I use a similar form for picking
objects using a dialogue in a modal window. For convenience I've
extracted the search form to a separate class which is now used
in both search panels.
Now, when the modal window is opened and the user selects
entries from the dropdowns, the ajax updates caused by the above
behaviours are "echoed" to the (still visible) search panel in
the underlying page, i.e., selections in its dropdowns change
etc.
I checked the following things:
- there are no hand-assigned markup IDs, i.e. the Ajax updates
operate on unique IDs.
- when I embed the panel in the page instead of a dialogue, the
effect disappears (however this is no option my customer would
accept)
- using dumb copy-and-paste instead of inheritance for the two
search forms does not help, i.e. the effect does not disappear
Since the application I'm dealing with is pretty complex, also
for confidence reasons, I can't really give any code examples
here.
I am using Wicket 6.12.
Has anyone ever experienced an effect like this? Any workaround
known? I feel pretty clueless with this problem..
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
Overflow on /dev/null, please empty the bit bucket.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange: Ajax-updates from a form inside a modal dialogue
"echoed" in the page underneath
Posted by Martin Dietze <di...@fh-wedel.de>.
Martin,
thanks a lot for your advice!
On Thu, February 06, 2014, Martin Grigorov wrote:
> Check the Ajax response after selecting a component.
> It contains <ajax-response> with <component id="..."> elements. The id
> attribute is used to find the old HTML element and to replace it with the
> new content.
> Since Wicket uses document.getElementByid() to find the old one I see no
> way how it will replace/update more than one HTML element in the page per
> <component>. So I guess there are <component>s for both the elements in the
> modal and in the page.
>
> The best is to debug it and fix it.
> A workaround is to use a Page for the Modal instead of a Panel.
Using the Ajax Debug panel I could track the problem down rather
easily. While the actual form components were "clean" I found
out that their surrounding containers, some of which were, too,
updated using Ajax were given fixed markup IDs from within the
Java code, so that I had two of them with the same IDs. Need to
do a 'git blame' on that one :)
Cheers,
M'bert
--
----------- / http://herbert.the-little-red-haired-girl.org / -------------
=+=
manche meinen, lechts und rinks kann man nicht velwechsern.
werch ein illtum! -- elnst jandr
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Strange: Ajax-updates from a form inside a modal dialogue
"echoed" in the page underneath
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Check the Ajax response after selecting a component.
It contains <ajax-response> with <component id="..."> elements. The id
attribute is used to find the old HTML element and to replace it with the
new content.
Since Wicket uses document.getElementByid() to find the old one I see no
way how it will replace/update more than one HTML element in the page per
<component>. So I guess there are <component>s for both the elements in the
modal and in the page.
The best is to debug it and fix it.
A workaround is to use a Page for the Modal instead of a Panel.
Martin Grigorov
Wicket Training and Consulting
On Thu, Feb 6, 2014 at 10:48 AM, Martin Dietze <di...@fh-wedel.de> wrote:
> I've just spent several hours trying to figure out what's going
> wrong here without any success. I am investigating a very
> strange effect:
>
> In my application I have a search panel in which several
> dropdowns are used to select search settings. Some of these
> settings depend on each other, so that they have their "change"
> events digested by AjaxFormComponentUpdatingBehavior.
>
> Now on a particular page I use a similar form for picking
> objects using a dialogue in a modal window. For convenience I've
> extracted the search form to a separate class which is now used
> in both search panels.
>
> Now, when the modal window is opened and the user selects
> entries from the dropdowns, the ajax updates caused by the above
> behaviours are "echoed" to the (still visible) search panel in
> the underlying page, i.e., selections in its dropdowns change
> etc.
>
> I checked the following things:
>
> - there are no hand-assigned markup IDs, i.e. the Ajax updates
> operate on unique IDs.
>
> - when I embed the panel in the page instead of a dialogue, the
> effect disappears (however this is no option my customer would
> accept)
>
> - using dumb copy-and-paste instead of inheritance for the two
> search forms does not help, i.e. the effect does not disappear
>
> Since the application I'm dealing with is pretty complex, also
> for confidence reasons, I can't really give any code examples
> here.
>
> I am using Wicket 6.12.
>
> Has anyone ever experienced an effect like this? Any workaround
> known? I feel pretty clueless with this problem..
>
> Cheers,
>
> M'bert
>
> --
> ----------- / http://herbert.the-little-red-haired-girl.org /
> -------------
> =+=
> Overflow on /dev/null, please empty the bit bucket.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>