AJAX im IE: responseXML nicht sinnvoll nutzbar

[Cheatah]

Hi,

ich führe mittels prototype.js einen AJAX-Request auf eine lokale XML-Ressource aus. Die responseText-Eigenschaft enthält auch den gesamten XML-Code, lediglich responseXML kann ich im IE 6 nicht vernünftig nutzen:

(Das von prototype.js gelieferte Transport-Objekt heißt bei mir 'data'.)

• Der XML-Code ist valide und wird auch vom IE erkannt. Das weiß ich, weil er sich anders verhalten hat, als ich dummerweise ein Sonderzeichen unkodiert drin stehen hatte ;-) und weil data.responseXML.documentElement.nodeName dem Root-Element entspricht.
• Ich kann mich mit firstChild, childNodes etc. durch das XML durchhangeln.
• Typische DOM-Methoden wie getElementsByTagName führen jedoch zum Script-Abbruch. Nicht etwa zu einem Fehler, sondern der IE scheint sich in eine Ecke zu setzen und zu schmollen.
• typeof() auf diese DOM-Methoden angewendet liefert 'unknown'. Ja, richtig gelesen: 'unknown', nicht 'undefined'.
• 'for (i in o)', wenn o entweder data.responseXML oder eines seiner Unterobjekte ist, führt ebenfalls zu einem fehlerlosen Abbruch,
• genauso wie 'irgendwoImHtml.appendChild(data.responseXML.irgendwas)'.
• Die Objekte haben weder eine toString-Methode, noch ein innerHTML (was nicht wundert), noch ein innerXML, egal in welcher Schreibweise (typeof() == 'undefined').
• Es ändert sich dabei nichts, wenn ich von 'data.responseXML.selectSingleNode("//meinRootElement")' ausgehe.

Insgesamt betrachtet kann ich den XML-Code also kein Stück benutzen. Der Server liefert als Content-Type text/xml oder application/xml (data.getAllResponseHeaders() bestätigt dies), das Dokument wird mit oder ohne '<?xml version="1.0" encoding="UTF-8"?>' ausgeliefert, die URI endet auf '.htmls' oder '.xml' - alles ohne Wirkung. Unnötig zu erwähnen, dass ich in Mozilla auf keinerlei nennenswerte Probleme stoße.

Was mich an der Geschichte am meisten verwirrt ist das 'unknown', welches wohl die Ursache für die Script-Abbrüche ohne Fehlermeldung ist. Ich finde im Netz aber auch keine gescheiten Informationen darüber (ist halt ein schlechter Suchbegriff ;-)). Kann mir jemand mehr darüber sagen? Gibt es eine Debugging-Strategie, die ich fahren kann, bzw. kennt oder erahnt jemand bereits die Ursache? Hat jemand eine Idee für einen Workaround, z.B. einen Ansatz, responseText "manuell" in XML umzuwandeln?

Cheatah

P.S.: Das XML besteht aus einem <multiparts>, in welchem sich n <part>-Elemente befinden, die schlicht und ergreifend HTML enthalten. Wenn es hilft, ließe sich dieser Teil als CDATA-Sektion deklarieren.

[svg4you]

Tach Cheatah,

P.S.: Das XML besteht aus einem <multiparts>, in welchem sich n <part>-Elemente befinden, die schlicht und ergreifend HTML enthalten.

Was liefert data.responseXML.getElementsByTagName("part").length?

Evtl. ist auch der Bezeichner data nicht so ganz glücklich gewählt, weil data bei Textknoten ein Alias für nodeValue ist.

Man liest sich,
svg4you

[Cheatah]

Hi,

Was liefert data.responseXML.getElementsByTagName("part").length?

nichts, weil data.responseXML.getElementsByTagName zu einem Abbruch führt. Über documentElement.childNodes kriege ich aber die richtige[1] Anzahl, und sie heißen auch "part".

Evtl. ist auch der Bezeichner data nicht so ganz glücklich gewählt, weil data bei Textknoten ein Alias für nodeValue ist.

typeof(foo.responseXML.getElementsByTagName) ist leider ebenfalls 'unknown'. Aber danke für diese Idee, darauf war ich noch gar nicht gekommen.

Cheatah

[1] Nun ja, für den IE richtig. Bei Mozilla sind es natürlich 2*n+1 childNodes, wegen der Whitespaces ;-)

[svg4you]

Tach Cheatah,

nichts, weil data.responseXML.getElementsByTagName zu einem Abbruch führt. Über documentElement.childNodes kriege ich aber die richtige[1] Anzahl, und sie heißen auch "part".

Zumindest ist das kein typisches IE6-Problem. Bei einem eigenen Projekt mit als text/xml ausgelieferter Response kann ich problemlos auf requestobj.responseXML.getElementsByTagName("...")[i] bzw. requestobj.responseXML.getElementsByTagName("...").item(i) zugreifen.

Man liest sich,
svg4you

[Cheatah]

Hi,

Zumindest ist das kein typisches IE6-Problem.

nein, ich habe auch zum ersten Mal damit Probleme. Der Code hat leider bereits einiges an Komplexität erlangt, so dass es mir schwer fällt, einen minimierten Testfall zu erstellen; aber eigentlich[tm] greife ich IMHO auf Dinge zu, die unabhängig von irgendwelchen Objektverschachtelungen und Event-Aktionen sein sollten. Zumal das XML an sich ja auch da zu sein scheint, nur dessen Methoden nicht ...

Cheatah

[zipdrive]

Ich habe übrigens das selbe Problem, ich kann mich nicht, trotz erfolgreichem responseXML, durch das Dokument hangeln! Das XML ist valide, bei Mozilla gehts ...

Wär cool, wenn dieses Problem mal einer gelöst hat, bzw die Ursache und Lösung kennt.

MfG

[Cybaer]

Hi,

Ich habe übrigens das selbe Problem,

Also zu Cheatahs Problem kann ich nichts sagen (oder wirkt da die gleiche Ursache?). Ich habe jedenfalls keinerlei IE-Probleme mit getElement... & Co. bei XMLHttpRequest. =:-o

Allerdings benutze ich auch nicht prototype.js. ;-)

ich kann mich nicht, trotz erfolgreichem responseXML, durch das Dokument hangeln! Das XML ist valide, bei Mozilla gehts ...

Das 1. Kind vom #document ist beim Mozilla das Root-Element. Beispiel:

<?xml...?>
<root>
 <child></child>
</root>

Also xhrobj.responseXML.firstChild.nodeName ist "root" - alles OK.

Beim IE ist das firstChild aber "xml" - und "root" ist xhrobj.responseXML.firstChild.nextSibling.nodeName.

Vielleicht hilft dir das? Jedenfalls hat mich das seinerzeit "gewundert". =;-)

Gruß, Cybaer

[Cheatah]

Hi,

Das 1. Kind vom #document ist beim Mozilla das Root-Element. Beispiel:
Also xhrobj.responseXML.firstChild.nodeName ist "root" - alles OK.
Beim IE ist das firstChild aber "xml" - und "root" ist xhrobj.responseXML.firstChild.nextSibling.nodeName.

hehe, die toDom()-Methode, mit der ich mal kurz experimentiert habe (s. Antwort auf MudGuards Posting), liefert im IE-Zweig domDoc.firstChild.nextSibling zurück ;-)

Vielleicht hilft dir das? Jedenfalls hat mich das seinerzeit "gewundert". =;-)

Mich auch, aber nur ein bisschen ... der IE macht ein dickes Fell *g*

Cheatah

[Axel Richter]

Hallo,

typeof(foo.responseXML.getElementsByTagName) ist leider ebenfalls 'unknown'. Aber danke für diese Idee, darauf war ich noch gar nicht gekommen.

Bei mir auch, obwohl getElementsByTagName trotzdem funktioniert. Und alert(foo.responseXML.getElementsByTagName) bringt den Fehler "Falsche Anzahl von Argumenten...", versucht also die Funktion auszuführen ;-), auch obwohl getElementsByTagName trotzdem funktioniert.

Was ergibt bei Dir:

alert(httpRequest.responseXML.nodeName);
   alert(httpRequest.responseXML.nodeType);

viele Grüße

Axel

[Axel Richter]

Hallo,

Was ergibt bei Dir:

alert(httpRequest.responseXML.nodeName);
   alert(httpRequest.responseXML.nodeType);

Soeben noch entdeckt

IXMLDOMDocument.xml bringt bei mir den XML-Inhalt des Dokuments (natürlich nur im IE).

viele Grüße

Axel

[Cybaer]

Hi,

IXMLDOMDocument.xml bringt bei mir den XML-Inhalt des Dokuments (natürlich nur im IE).

BTW: Für meine innerXML()-Funktion hätte ich gerne optional auch den Doctype ausgegeben. xml liefert zwar den Doctype, aber leider nicht vollständig (die "version" und "standalone" steht zwar drin, "encoding" jedoch nicht). Da der IE die diesbezügl. Standardeigenschaften (xmlEncoding, ...) nicht kennt, die Frage: Ist dir eine andere Möglichkeit bekannt, diese Info zu bekommen?

Gruß, Cybaer

[Axel Richter]

Hallo,

BTW: Für meine innerXML()-Funktion hätte ich gerne optional auch den Doctype ausgegeben. xml liefert zwar den Doctype, aber leider nicht vollständig (die "version" und "standalone" steht zwar drin, "encoding" jedoch nicht). Da der IE die diesbezügl. Standardeigenschaften (xmlEncoding, ...) nicht kennt, die Frage: Ist dir eine andere Möglichkeit bekannt, diese Info zu bekommen?

Nein, wie gesagt, ich habe die Eigenschaft IXMLDOMDocument.xml soeben erst entdeckt.

Wenn nichts Anderes hilft, kann man das Encoding aus dem onimösen ersten ChildNode des Dokuments im IE mit

httpRequest.responseXML.firstChild.text
oder
httpRequest.responseXML.firstChild.nodeValue

herauslesen.

viele Grüße

Axel

[Cybaer]

Hi,

Wenn nichts Anderes hilft, kann man das Encoding aus dem onimösen ersten ChildNode des Dokuments im IE (...) herauslesen.

Klar, danke für den Tip. =%-)

Gruß, Cybaer

[MudGuard]

Hi,

BTW: Für meine innerXML()-Funktion hätte ich gerne optional auch den Doctype ausgegeben. xml liefert zwar den Doctype, aber leider nicht vollständig (die "version" und "standalone" steht zwar drin, "encoding" jedoch nicht).

version, standalone oder encoding gibt es im Doctype gar nicht. Versuche, darauf zuzugreifen, sollten also in jedem Fall scheitern.
Im Doctype gibt es den Namen des root Elements sowie public identifier und system identifier.

cu,
Andreas

[Cybaer]

Hi,

version, standalone oder encoding gibt es im Doctype gar nicht.

(pfeif) Wie gut, daß Axel wußte, was ich *meinte*. =;)

Gruß, Cybaer

[Cheatah]

Hi,

typeof(foo.responseXML.getElementsByTagName) ist leider ebenfalls 'unknown'.
Bei mir auch, obwohl getElementsByTagName trotzdem funktioniert.

erstaunlich, bei mir im Moment auch. Jetzt muss ich nur noch herausfinden, welche Umstände das ändern, denn vorhin ging es ja definitiv nicht - sonst wäre ich nicht auf die Idee gekommen, mir mal den typeof() ausgeben zu lassen ;-) Erster Gedanke: Browsercache, obwohl ich den regelmäßig zerhäckselt habe. Ich prüfe.

Und alert(foo.responseXML.getElementsByTagName) bringt den Fehler "Falsche Anzahl von Argumenten...", versucht also die Funktion auszuführen ;-),

Jessas!

Was ergibt bei Dir:
   alert(httpRequest.responseXML.nodeName);
   alert(httpRequest.responseXML.nodeType);

#document und 9, also das Richtige.

Cheatah

[Axel Richter]

Hallo,

erstaunlich, bei mir im Moment auch. Jetzt muss ich nur noch herausfinden, welche Umstände das ändern, denn vorhin ging es ja definitiv nicht - sonst wäre ich nicht auf die Idee gekommen, mir mal den typeof() ausgeben zu lassen ;-) Erster Gedanke: Browsercache, obwohl ich den regelmäßig zerhäckselt habe. Ich prüfe.

Offensichtlich erfolglos ;-)?

Da sich ohnehin eine only-for-IE-Variante, wie auch immer, abzeichnet, könntest Du auch

oXMLDOMNode.selectNodes(expression)

und/oder

oXMLDOMNode.selectSingleNode(queryString)

eine Chance geben. Bei mir laufen beide Methoden im IE wie beschrieben. Sie werden auch in der Beschreibung von oXMLDOMDocument.getElementsByTagName(tagName) als Ersatz angeführt, zwar nur dann, wenn Namespace-Support benötigt wird, aber man weiß ja nie ;-).

viele Grüße

Axel

[Cheatah]

Hi,

erstaunlich, bei mir im Moment auch. Jetzt muss ich nur noch herausfinden, welche Umstände das ändern, denn vorhin ging es ja definitiv nicht - sonst wäre ich nicht auf die Idee gekommen, mir mal den typeof() ausgeben zu lassen ;-) Erster Gedanke: Browsercache, obwohl ich den regelmäßig zerhäckselt habe. Ich prüfe.
Offensichtlich erfolglos ;-)?

bisher ja - und ich gebe zu, die Tendenz geht in Richtung "egal", zumal es ja jetzt funktioniert ;-)

Da sich ohnehin eine only-for-IE-Variante, wie auch immer, abzeichnet, könntest Du auch [...]
oXMLDOMNode.selectSingleNode(queryString)
eine Chance geben.

Nun ja, den ersten Versuch hiervon habe ich bereits im Ausgangsposting notiert *g*

Was die IE-only-Variante betrifft: Da steckt im Moment hier und dort ein entsprechendes Code-Schnipselchen drin. Ich werde mal sehen, ob ich das jeweils an geschicktere Stellen verlagern kann.

Cheatah

[Axel Richter]

Hallo,

typeof(foo.responseXML.getElementsByTagName) ist leider ebenfalls 'unknown'.
Bei mir auch, obwohl getElementsByTagName trotzdem funktioniert. Und alert(foo.responseXML.getElementsByTagName) bringt den Fehler "Falsche Anzahl von Argumenten...", versucht also die Funktion auszuführen ;-),

Offensichtlich hat Microsoft sich nicht die Mühe gemacht, um die Msxml2-Objekte die üblichen Script-Wrapper drumzulegen. Man greift hier offensichtlich direkt auf [native code] zu. Anders ist das folgende Verhalten bald nicht zu erklären:

  
try {  
 alert(document.getElementsByTagName);  
} catch(e) {  
 alert(e.description);  
}  
try {  
 for (member in document) document.write(member + "<br/>");  
} catch(e) {  
 alert(e.description);  
}  
  
//versus  
  
var objDoc = new ActiveXObject("Msxml2.DOMDocument.3.0");  
try {  
 alert(objDoc.getElementsByTagName);  
} catch(e) {  
 alert(e.description);  
}  
try {  
 for (member in objDoc) document.write(member + "<br/>");  
} catch(e) {  
 alert(e.description);  
}  

Damit entfallen natürlich fast alle üblichen Methoden des JavaScript-debugging, leider.

Interessant wäre zu wissen, ob jemand schon weitergehende andere Konzepte zum Debuggen von Code mit MSXML2-Objekten entwickelt hat.

viele Grüße

Axel

[Cheatah]

Hi,

Offensichtlich hat Microsoft sich nicht die Mühe gemacht, um die Msxml2-Objekte die üblichen Script-Wrapper drumzulegen. Man greift hier offensichtlich direkt auf [native code] zu. Anders ist das folgende Verhalten bald nicht zu erklären:

[...]

danke für Deine Analyse.

Damit entfallen natürlich fast alle üblichen Methoden des JavaScript-debugging, leider.

Ja, sehr schade. Andererseits überrascht es nicht - das Debugging im IE war schon immer schwer bis unmöglich. Die angebliche Datei, in der ein Fehler auftritt, ist immer die URL der gerade im Browser angezeigten Ressource; und am Ende sucht man sich tot, in welcher Datei bei ungefähr(!) der angegebenen Zeile etwas passieren könnte. Die wichtigste Information ist im großen und ganzen die Spalte, und das ist schon reichlich peinlich.

Interessant wäre zu wissen, ob jemand schon weitergehende andere Konzepte zum Debuggen von Code mit MSXML2-Objekten entwickelt hat.

Wenn Du dazu was Brauchbares findest, dann besteche ich jemanden, Dir dafür ein Küsschen zu geben ;-)

Cheatah

[Cybaer]

Hi,

Wenn Du dazu was Brauchbares findest, dann besteche ich jemanden, Dir dafür ein Küsschen zu geben ;-)

Gernot? *SCNR*

Gruß, Cy-"nach Diktat verreist"-baer

[Jörg Peschke]

Moin Cheatah,
Ein Erlaubnisproblem kanns nicht sein, oder?
Das frage ich, weil wir jüngst das Problem mit einem auf einer Seite herumgeisternden "document.domain = irgendwas" hatten, welches zwar den Zugriff auf "responseXML" oder "responseText" prinzipiell erlaubte, bei "getElemntsBytagName" warf der Mozilla aber eine Exception (wegen Same Origin Policy).

Nur so ne Idee.

Viele Grüße,
Jörg

[Cheatah]

Hi,

Ein Erlaubnisproblem kanns nicht sein, oder?

nein, es ist der selbe Server, und Mozilla erlaubt mir auch beliebige DOM-Zugriffe. Es könnte höchstens sein, dass mein IE verkonfiguriert ist, aber ehrlich gesagt glaube ich da nicht dran; und das nicht nur, weil das Problem auf einem anderen PC reproduzierbar ist.

Das frage ich, weil wir jüngst das Problem mit einem auf einer Seite herumgeisternden "document.domain = irgendwas" hatten, welches zwar den Zugriff auf "responseXML" oder "responseText" prinzipiell erlaubte, bei "getElemntsBytagName" warf der Mozilla aber eine Exception (wegen Same Origin Policy).

Und bei firstChild u.ä.?

Cheatah

[Jörg Peschke]

Hallo,

Und bei firstChild u.ä.?

Das habe ich dann nicht weiter probiert, da es generell um das Problem ging, dass das Setzen von document.domain und AJAX sich nicht vertragen (dazu gibts diverse Posts im Web).

Klingt aber bei Dir nach einem anderen Problem, da es bei mir gerade der Mozilla war, der Zicken gemacht hat (der nimmt ja die SOP etwas genauer) - und der scheint ja bei Dir keine Probleme zu machen.

Sorry, da bin ich dann wohl überfragt :(

Viele Gruesse,
Joerg

[Cheatah]

Hi,

Klingt aber bei Dir nach einem anderen Problem, da es bei mir gerade der Mozilla war, der Zicken gemacht hat (der nimmt ja die SOP etwas genauer) - und der scheint ja bei Dir keine Probleme zu machen.

richtig ...

Sorry, da bin ich dann wohl überfragt :(

Macht nichts, danke trotzdem!

Cheatah

[Andreas Dölling]

Hallo,

Insgesamt betrachtet kann ich den XML-Code also kein Stück benutzen. Der Server liefert als Content-Type text/xml oder application/xml (data.getAllResponseHeaders() bestätigt dies)

ich hatte Anfang des Jahres ein ähnliches (oder dasselbe) Problem, meine aber, daß es bei mir damit zusammenhing, daß der Server nicht den richtigen Header mitgeschickt hat. Die Angabe <?xml version="1.0" encoding="utf-8" ?> im XML-Dokument hat nicht gereicht. Mein Backend-Kollege mußte noch explizit den Content-type per header("Content-type: application/xml"); mitgeben - dann funktionierte alles.
Aber das scheint bei Dir ja schon alles richtig zu laufen - insofern: leider keine andere Idee von meiner Seite.
:/

Ciao,
Andreas

[Cheatah]

Hi,

Aber das scheint bei Dir ja schon alles richtig zu laufen - insofern: leider keine andere Idee von meiner Seite.

macht nichts, trotzdem danke für Deine Anteilnahme :-)

Cheatah

[Andreas Dölling]

Hallo,

macht nichts, trotzdem danke für Deine Anteilnahme :-)

ok, Rechnung kommt!
;)

Ciao,
Andreas

[MudGuard]

Hi,

• Typische DOM-Methoden wie getElementsByTagName führen jedoch zum Script-Abbruch. Nicht etwa zu einem Fehler, sondern der IE scheint sich in eine Ecke zu setzen und zu schmollen.

Sind da evtl. namespaces im Spiel, die das Problem verursachen?

• typeof() auf diese DOM-Methoden angewendet liefert 'unknown'. Ja, richtig gelesen: 'unknown', nicht 'undefined'.

Seltsam. (also genau das, was man vom IE erwartet ...)

• genauso wie 'irgendwoImHtml.appendChild(data.responseXML.irgendwas)'.

Beim IE hatte ich Probleme, nodes, die in einem document erzeugt wurden, in ein anderes document einzuhängen ...

P.S.: Das XML besteht aus einem <multiparts>, in welchem sich n <part>-Elemente befinden, die schlicht und ergreifend HTML enthalten.

HTML? Das könnte natürlich Probleme geben - Doctype mitten im XML ...
Selbst bei HTML-Fragmenten könnte das Probleme geben (<hr>, <br> ...)
Oder sind es XHTML-Fragmente?

Hast Du mal versucht, aus responseText ein XML-Dokument erzeugen zu lassen?
Per
xmlObj = new ActiveXObject("Msxml2.DOMDocument");
xmlObj.loadXML(http.responseText);
(oder so ähnlich).

Oder einfach den responseText per innerHTML in ein beliebiges Element einfügen und dann dadrin arbeiten ...

cu,
Andreas

[Cheatah]

Hi,

Sind da evtl. namespaces im Spiel, die das Problem verursachen?

nein. Es gibt auch keinen DOCTYPE, sondern lediglich <multiparts> und <part>, in dem sich stinknormaler XHTML-Code befindet. Streng genommen ist der Code reichlich primitiv ;-)

Seltsam. (also genau das, was man vom IE erwartet ...)

Ja, genau ... *örgl*

• genauso wie 'irgendwoImHtml.appendChild(data.responseXML.irgendwas)'.
  Beim IE hatte ich Probleme, nodes, die in einem document erzeugt wurden, in ein anderes document einzuhängen ...

Ah. Konntest Du das Problem lösen?

Oder sind es XHTML-Fragmente?

Ja, das meinte ich, sorry.

Hast Du mal versucht, aus responseText ein XML-Dokument erzeugen zu lassen?

Ja, allerdings mit new ActiveXObject("Microsoft.XMLDOM") und .loadXML(). Die Effekte waren ... zahl- aber wenig hilfreich. Ich probiere es mal mit Msxml2.DOMDocument.

Oder einfach den responseText per innerHTML in ein beliebiges Element einfügen und dann dadrin arbeiten ...

Habe ich auch überlegt, aber das wäre recht krebselig. Das <part>-Element kann Attribute enthalten, die etwas weiter oben im Baum übernommen werden müssten; außerdem muss ich die einzelnen <part>s separat betrachten und einfügen.

Cheatah

[Cheatah]

Hi,

Ja, allerdings mit new ActiveXObject("Microsoft.XMLDOM") und .loadXML(). Die Effekte waren ... zahl- aber wenig hilfreich. Ich probiere es mal mit Msxml2.DOMDocument.

  
String.prototype.toDom = function() {  
    // [...]  
    var domDoc = new ActiveXObject("Msxml2.DOMDocument");  
    if(domDoc) {  
        domDoc.async = false;  
        domDoc.loadXML(this.toString());  
        return domDoc.firstChild.nextSibling;  
    }  
}  
  
// [...]  
var xml = data.responseText.toDom();  
alert(typeof(xml.firstChild.getElementsByTagName)); // liefert 'unknown'  

Erstmalig[1] habe ich jetzt getElementById ausprobiert - und siehe da, die Methode ist nicht unknown. Nein, sie ist - tadaa! - undefined. Hilft das weiter?

Cheatah

[1] Huch![tm] :-)

[Cybaer]

Hi,

Erstmalig[1] habe ich jetzt getElementById ausprobiert - und siehe da, die Methode ist nicht unknown. Nein, sie ist - tadaa! - undefined. Hilft das weiter?

Also ich habe es auch mal bei mir mit typeof() getestet:

alert(typeof(requestObj.responseXML.getElementsByTagName))

ergab das "unknown" (nie bemerkt). Aber bei meiner Testdatei

<?xml...?>
<root>
 <child>Test</child>
</root>

ergibt ein alert(requestObj.responseXML.getElementsByTagName("child")[0].firstChild.nodeValue) ein korrektes "Test". Und ich habe auch keinerlei Problem, dort mit createElement/appendChild neue Elemente einzufügen.

Gruß, Cybaer

[Cheatah]

Hi,

Also ich habe es auch mal bei mir mit typeof() getestet:
[...] alert(requestObj.responseXML.getElementsByTagName("child")[0].firstChild.nodeValue) ein korrektes "Test".

ja, siehe https://forum.selfhtml.org/?t=134713&m=874272.

Und ich habe auch keinerlei Problem, dort mit createElement/appendChild neue Elemente einzufügen.

Die Probleme bestehen bei mir leider weiterhin; Experimente mit cloneNode blieben erfolgfrei. Ich habe mich jetzt damit beholfen, innerHTML stetig zu erweitern.

Lohnt es sich zu versuchen, dem IE per Prototyping ein Element.toString() unterzujubeln? Soweit ich mich erinnere, kennt er die entsprechenden Objekte nicht; man muss sie ihm per .htc-Datei und behaviour-Eigenschaft beibringen. Derzeit ist ein 'x.toString ? x.toString() : x.xml' recht hässlich, aber wirksam.

Cheatah

[Cybaer]

Hi,

Lohnt es sich zu versuchen, dem IE per Prototyping ein Element.toString() unterzujubeln?

Ich löse das einfach mit schlichten Funktionen (innerXML(), outerXML() und innerText()) - von Microsoft lernen heißt siegen lernen. ;->

Derzeit ist ein 'x.toString ? x.toString() : x.xml' recht hässlich, aber wirksam.

Hmm, dir ist aber schon bewußt, daß das empfangene XML-Dokument als Plaintext bereits in responseText steht?

Gruß, Cybaer

[Cheatah]

Hi,

Ich löse das einfach mit schlichten Funktionen

Funktionen oder Methoden?

von Microsoft lernen heißt siegen lernen. ;->

Ich bin aber kein Sieger, sondern Software-Entwickler - und von der Thematik hat Microsoft nun mal keine Ahnung ;-)

Hmm, dir ist aber schon bewußt, daß das empfangene XML-Dokument als Plaintext bereits in responseText steht?

Sicher doch. Ich benötige allerdings die Inhalte einzelner Elemente.

Cheatah

[Cybaer]

Hi,

Ich löse das einfach mit schlichten Funktionen
Funktionen oder Methoden?

Funktionen - ganz schlicht! Also z.B. alert(innerXML(requestObj.responseXML.getElementsByTagName("child")[0]) würde in meinem Beispiel einen Alert mit "Test" liefern - oder ein "<b>kleiner</b> Test" wenn entsprechendes drin stünde. ;-) Ein innerText(...) dann analog ein "kleiner Test". Halt wie innerHTML, outerHTML und innerText vom IE bei HTML-Dokumenten - nur eben als Funktion.

von Microsoft lernen heißt siegen lernen. ;->
Ich bin aber kein Sieger, sondern Software-Entwickler - und von der Thematik hat Microsoft nun mal keine Ahnung ;-)

:)))

Gruß, Cybaer

[Cheatah]

Hi,

Funktionen - ganz schlicht!

okay. Übrigens scheint Deine "e"-Taste gelegentlich ein "i" zu produzieren, ähem :-)

Funktionen versuche ich mir tendenziell abzugewöhnen. Die sind zwar paradoxerweise klassisch, aber nicht wirklich methodisch ... Derzeit arbeite ich mit einem Klassenkonzept, dass sich äußerst geschmeidig ins Dokument fügt. Wenn ich da ein innerXML() hinein erfinden möchte, dann wird es ganz sicher bei Prototype geschehen - schon alleine des Prinzips wegen. Es handelt sich um die Startseite eine ziemlich bekannten Firma, die täglich mit Millionen Besuchern zu rechnen hat. Ich möchte, dass ein technisch versierter Betrachter trotz aller (sicherlich gerechtfertigten) Kritik den Code als zielführend und in sich stimmig empfindet ... statt wie bisher als eine Farce ;-)

Cheatah

[Cybaer]

Hi,

Funktionen - ganz schlicht!
okay. Übrigens scheint Deine "e"-Taste gelegentlich ein "i" zu produzieren, ähem :-)

Das ist der Platzhalter für "soll problemlos auf allem laufen, was sich Browser nennt". ;)

Funktionen versuche ich mir tendenziell abzugewöhnen. Die sind zwar paradoxerweise klassisch, aber nicht wirklich methodisch ...

Ja, schon klar - aber der Geist ist willig, das Fleisch hingegen ... ;-)

Es handelt sich um die Startseite eine ziemlich bekannten Firma, die täglich mit Millionen Besuchern zu rechnen hat.

Arbeitest Du in/für "Karlsruhe"? ;-)

Ich möchte, dass ein technisch versierter Betrachter trotz aller (sicherlich gerechtfertigten) Kritik den Code als zielführend und in sich stimmig empfindet ... statt wie bisher als eine Farce ;-)

=:->

Na ja, ist ja auch Ansichtssache. Aber das fällt für *meine* Arbeit unter die Kategorie "Schönheitsoperation". :) Ich muß erstmal sehen, daß der Rest der Logik stabil läuft. Und wenn das der Fall ist, gibt es "die Kür". ;-))

Gruß, Cybaer

[Cheatah]

Hi,

Funktionen versuche ich mir tendenziell abzugewöhnen. Die sind zwar paradoxerweise klassisch, aber nicht wirklich methodisch ...
Ja, schon klar - aber der Geist ist willig, das Fleisch hingegen ... ;-)

[dsf 2.7] ;-)

Es handelt sich um die Startseite eine ziemlich bekannten Firma, die täglich mit Millionen Besuchern zu rechnen hat.
Arbeitest Du in/für "Karlsruhe"? ;-)

Och, wieso? *pfeif* :-)

Na ja, ist ja auch Ansichtssache. Aber das fällt für *meine* Arbeit unter die Kategorie "Schönheitsoperation". :) Ich muß erstmal sehen, daß der Rest der Logik stabil läuft. Und wenn das der Fall ist, gibt es "die Kür". ;-))

Ich war selbst überrascht, wie gut mein Code (bisher) lief. Die eigentliche Funktionalität hatte ich ziemlich schnell implementiert, und zwar mit einem recht simplen, aber dennoch IMHO ordentlich objektorientierten Ansatz. Im Grunde ist es bei mir also gegenteilig: Ich mache keine Schönheitsoperationen, sondern vermeide es, Narben ins Fleisch zu schneiden.

Cheatah

[Cybaer]

Hi,

Ja, schon klar - aber der Geist ist willig, das Fleisch hingegen ... ;-)
[dsf 2.7] ;-)

Gibt es eine dsf für "muß schnell und sicher laufen" von Controllern, die "OOP" höchstens bei Nerd-Gesprächen in der Kantine aufschnappen? ;)

Arbeitest Du in/für "Karlsruhe"? ;-)
Och, wieso? *pfeif* :-)

(Halb) rhetorische Frage. Mich beschlich der Verdacht, daß so ziemlich jeder, der was von JS versteht, mom. auch in/für "Karlsruhe" arbeitet? ;-)

Im Grunde ist es bei mir also gegenteilig: Ich mache keine Schönheitsoperationen, sondern vermeide es, Narben ins Fleisch zu schneiden.

Na ja, deswegen bist Du ja Cheatah und ich Cybaer. ;-)

Und wenn es alle gleich machen würden, wär die Welt ja auch langweilig ... ;)

Gruß, Cybaer

[MudGuard]

Hi,

Seltsam. (also genau das, was man vom IE erwartet ...)
Ja, genau ... *örgl*

• genauso wie 'irgendwoImHtml.appendChild(data.responseXML.irgendwas)'.
  Beim IE hatte ich Probleme, nodes, die in einem document erzeugt wurden, in ein anderes document einzuhängen ...
  Ah. Konntest Du das Problem lösen?

Jein. Ich hab die nodes selbst-geklont, sprich mir den Nodename und sämtliche Attribute geholt und damit im anderen Dokument per document.createElement usw. das Element nochmal erzeugt, das ganze dann natürlich auch noch für die Kinder, Enkel usw. rekursiv.

Hast Du mal versucht, aus responseText ein XML-Dokument erzeugen zu lassen?
Ja, allerdings mit new ActiveXObject("Microsoft.XMLDOM") und .loadXML(). Die Effekte waren ... zahl- aber wenig hilfreich. Ich probiere es mal mit Msxml2.DOMDocument.

Viel Erfolg!

Oder einfach den responseText per innerHTML in ein beliebiges Element einfügen und dann dadrin arbeiten ...
Habe ich auch überlegt, aber das wäre recht krebselig. Das <part>-Element kann Attribute enthalten, die etwas weiter oben im Baum übernommen werden müssten; außerdem muss ich die einzelnen <part>s separat betrachten und einfügen.

Ne, nicht da endgültig einhängen. Sondern einhängen, um es von dort aus auslesen zu können und dann die Schritte zu unternehmen, die du sonst auf responseXML gemacht hättest, sozusagen

document.getElementById("tempXMLcontainer").innerHTML = responseText;
mypart = document.getElementById("tempXMLcontainer").getElementsByTagName("parts")[42]

statt

mypart = responseXML.getElementsByTagName("parts")[42];

cu,
Andreas

[Cheatah]

Hi,

Ah. Konntest Du das Problem lösen?
Jein. Ich hab die nodes selbst-geklont, sprich mir den Nodename und sämtliche Attribute geholt und damit im anderen Dokument per document.createElement usw. das Element nochmal erzeugt, das ganze dann natürlich auch noch für die Kinder, Enkel usw. rekursiv.

au, geil. Wir basteln uns ein(en) DOM.

Ja, allerdings mit new ActiveXObject("Microsoft.XMLDOM") und .loadXML(). Die Effekte waren ... zahl- aber wenig hilfreich. Ich probiere es mal mit Msxml2.DOMDocument.
Viel Erfolg!

Danke. Die Ergebnisse beider ActiveX-Objekttypen waren (augenscheinlich) identisch, aber das Problem hat sich sowieso durch irgend einen Voodoo-Zauber in Wohlgefallen[tm] aufgelöst.

Ne, nicht da endgültig einhängen. Sondern einhängen, um es von dort aus auslesen zu können und dann die Schritte zu unternehmen, die du sonst auf responseXML gemacht hättest,

Ach so, dieser Workaround, ja. Danke.

Cheatah

[Gunnar Bittersmann]

Hello out there!

au, geil. Wir basteln uns ein(en) DOM.

Schaffe, schaffe, Häusle baue. (In den slawischen Sprachen heißt „dom“ „Haus“. Ich weiß jetzt nicht, ob das Wort denselben Ursprung hat wie der deutsche „Dom“, wär aber möglich.)

See ya up the road,
Gunnar