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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange: Ajax-updates from a form inside a modal dialogue echoed in the page underneath
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 components 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 d...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Strange: Ajax-updates from a form inside a modal dialogue echoed in the page underneath
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 components 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
