Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>After working through this problem and the prior answer given, I discovered some important details missing from the answer. The most important point here is that while <code>.dialog("destroy")</code> does restore the div to its pre-init state, it DOES NOT restore the div to its original location in the DOM. (BAHDev's question mentions how UI Dialog moves the div in the first place.) This is critical to the Ajax operation and this change/non-change of the div location should be clarified in the jQuery documentation (that would have saved me a lot of time).</p> <p>If Ajaxing only the contents of the dialog div, then this behavior probably is not critical since you can easily find and rewrite the div contents no matter where it resides in the DOM. If your dialog content gets Ajaxed inline with other objects, however, then moving a div from its original location will likely cause later Ajaxing to create another div in the original location resulting in multiple divs of the same ID.</p> <p>For example, I request a short list of products and a long list of products in one Ajax call. The short list goes to the screen and the long list goes to a hidden dialog. Because the lists are related, it makes sense to grab them both in one Ajax call. Because UI Dialog moved the long list out of the container it was Ajaxed into and stuck it at the end of the HTML body, when I request a new list, I end up with two divs with the same ID, each containing a different long list -- one in the Ajax container, and one at the end of the body. The most correct way I see to handle this is to first completely destroy the old long list before Ajaxing a new one. (One could also check for UI Dialog objects and move the long list in code but that is cumbersome and may also lose div attributes.)</p> <p>In testing (jQuery 1.4.4, UI 1.8.10), I found that <code>.dialog("destroy")</code> on the original div works exactly the same as <code>.remove()</code> on the UI Dialog parent div. That is, only the UI Dialog wrapper divs are stripped away, and the original div is left behind in its original state. In other words, each of the following does the same thing [note: .empty() had no noticeable effect]:</p> <pre><code>// Three different ways to destroy just the UI Dialog // (and leave the original div). $(".ui-dialog:has(#myDialog)").remove(); $("#myDialog").parents(".ui-dialog").remove(); $("#myDialog").dialog("destroy"); </code></pre> <p>Thus, the best way to destroy both the UI Dialog wrapper AND the original div appears to be this:</p> <pre><code>// Remove the old dialog and div to make way for a new one via Ajax. $("#myDialog").dialog("destroy"); $("#myDialog").remove(); </code></pre> <p>If you want to be sure you destroy all copies -- in case you accidentally create too many with too many calls to <code>.dialog()</code> -- you need something in front of the #id selector, such as:</p> <pre><code>// Remove all old dialogs and divs to make way for a new one via Ajax. $("div#myDialog").dialog("destroy"); $("div#myDialog").remove(); </code></pre> <p>You could do this in one line but it is less apparent what your intent is:</p> <pre><code>// Remove all old dialogs and divs to make way for a new one via Ajax. // This technique is not recommended. $("div#myDialog").parents(".ui-dialog").andSelf().remove(); </code></pre> <p>I tested all of this in FF and some of it in IE8.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload