I have a large number of ASP.NET web services that feed data-driven content to Mootools-based AJAX requests; most of them return ASP.NET XmlNodes (XHTML).
Using Request.HTML works great in non-IE browsers. Unfortunately, IE interprets the XmlNode structure as ixmldomnodelist, instead of a traditional DOM object. Not a problem for the most part, until we get to Element.empty(). Here's the sequence: - Initial page draw includes: <div id="mytag">.</div> - Invoke Request.HTML with an update: 'mytag' option set - server returns an XmlNode / XHTML (the relevent part here is, I believe, an XML declaration as the first line) - Request.success calls document.id[this.update].empty().set(...) - The div tag now contains the full XHTML returned (including the XML declaration) (so far, so good) - Invoke Request.HTML to refresh the content (update: 'mytag' again) - server returns same content - Request.success calls document.id[this.update].empty().set(...) - an error is thrown, since IE casts document.id[this.update] as an IXmlDOMNodeList I had a few possible workarounds: - override Request.success to call document.id[this.update].set(...) - bypasses empty, which fails to destroy objects elegantly, so I run the risk of memory leaks - currently using this - override Element.empty to explicitly handle IXmlDOMNode issues - more work, and I'm lazy - override Element.set() to trap for xml declarations, and "convert" to traditional DOM - probably the best, but again, I'm lazy - rewrite several hundred web service methods to return strings - not viable; we have clients who bind to the WSDLs and expect XmlNode instead of a string Any thoughts or suggestions on the best approach? Eric
