[JS] XMLHttpRequest - Geen nodeValue of textContent?

[r0bert]

Hoewel ik in mijn andere topic ook over dit onderwerp bezig was, vond ik het niet meer goed onder de titel passen - vandaar een nieuw topic.

Ik heb XMLHttpRequest (XHR) geimplementeerd in mijn webpagina. Nu wil ik echter aan de hand van de teruggegeven elementen wat verschillende acties uithalen. Een daarvan is om op de client een functiebibliotheek op te bouwen. Voorkeur heeft het om scripts met een 'src' toe te voegen, aangezien deze beter gecached worden. Maar af en toe zullen het ook eens custom functies zijn. Daarbij moet ik de inhoud van het element uitlezen en deze toevoegen aan de eigenlijke pagina om de functie uit te kunnen voeren. Dat uitlezen werkt om de één of andere vage reden niet.

Hier een snippet van de bijbehorende code:

JavaScript:

     //[.. snip ..]
    server.connections.parseResponseDOM(this.responseXML); // Start with the root. 0 = XML decl.
},


// Parse the response XML DOM.
// We only need new javascript function. Save our bandwidth!
parseResponseDOM : function(oDOMElm)
{               
    if (oDOMElm.hasChildNodes == false) return;
    
    // else
    var iChild = 0;
    while (oChild = oDOMElm.childNodes[iChild++])
    {
        // Switch (prefix:nodeName) - Empty prefix is not rendered
        switch (oChild.nodeName)
        {
            case 'core:action':
                alert('action');
                
            case 'core:function':
            ////  WERKT NIET!?  ////
            alert(oChild.nodeValue);
            ////////////////////////
                oScript             = document.createElement('script');
                oScript.type    = 'text/javascript';
                oScript.id      = oChild.getAttribute('id');
                oScript.text    = oChild.textContent;
                
            case 'core:script':
                alert('script');
                
                
            default:
                this.parseResponseDOM(oChild);
                // If only default - Do nothing, just go on parsing - else, go on parsing
        }
    }
    return;
}

Ik heb vele alternatieven geprobeerd en ook een goede reference geprobeerd te zoeken. Zonder succes. Ik heb verder nog geprobeerd

JavaScript:

.textContent
.text
.data
.responseText
.textValue

.firstChild.*

Alles staat overigens in een CDATA:

XML:

..
    <core:action>
        <core:function id="doRaar">
            <![CDATA[
            var ik='gek';
                function doRaar()
                {   alert(ik);
                }
            ]]>
        </core:function>        
        <core:script>
            <![CDATA[
            doRaar();
            ]]>
        </core:script>
    </core:action>
..

[ Voor 12% gewijzigd door r0bert op 14-04-2008 14:43 ]

[crisp]

Op die manier script toevoegen werkt inderdaad niet (en .text is al helemaal niet DOM-compliant). Je zal zelf het script moeten evalueren (met eval() inderdaad)

[r0bert]

Deze workaround kwam ik tegen via Google en behoort wel te 'werken'. Iig, zo heb ik vaker wél scripts toegevoegd. Netjes is anders, maar hé, da's hetzelfde verhaal met eval().

Maar ook als ik eval() zou gebruiken, moet ik de 'nodeValue' nog wel uit kunnen lezen. Dat werkt niet (zie alert)?
http://sove.nl/js.html

Ik snap ook niet waarom ik twee keer in de 'core:function'-case beland

Edit:
Het lijkt een beetje op een caching probleem van IE. Ik ga dat eerst even verhelpen, mogelijk helpt dat al een boel. Dat ik twee keer in core:function beland is één keer vanuit het werkelijke element en één keer vanuit de CDATA waarbij het dus de nodeName van de parent pakt. Vreemd.

[ Voor 40% gewijzigd door r0bert op 14-04-2008 15:17 ]

[crisp]

normaliter zou je firstChild.nodeValue pakken (pas dan wel op met whitespace voor/na je CDATA section), maar textContent lijkt iig in Firefox ook gevuld te zijn.

[r0bert]

crisp schreef op maandag 14 april 2008 @ 14:55:
Op die manier script toevoegen werkt inderdaad niet (en .text is al helemaal niet DOM-compliant). Je zal zelf het script moeten evalueren (met eval() inderdaad)

IE vind het op het moment best, FireFox niet.Beide lijken het best te vinden. Ook niet heel vreemd natuurlijk

crisp schreef op maandag 14 april 2008 @ 15:18:
normaliter zou je firstChild.nodeValue pakken (pas dan wel op met whitespace voor/na je CDATA section), maar textContent lijkt iig in Firefox ook gevuld te zijn.

Bij mij bleef alles leeg in FF....... idd de whitespace Het blijft prutsen. Vind ze er maar raar mee om gaan, nodeName en nodeType van de parent gebruiken e.d.

Het wordt er niet mooier op, niet iemand die trucjes in huis heeft om alsnog de evil eval te ontwijken?

[ Voor 47% gewijzigd door r0bert op 14-04-2008 15:45 ]

[Verwijderd]

eval is niet evil als je javascript wil evalueren, daar is het namelijk precies voor bedoeld.

in het geval van je function element zou ik overigens de Function constructor gebruiken, daar is die namelijk weer voor bedoeld

[ Voor 41% gewijzigd door Verwijderd op 14-04-2008 16:55 ]

[r0bert]

Die function constructor is inderdaad een goed idee! Daar ga ik mee aan de slag (hoewel het nu werkte in IE en FF).

Ik snap de bedoeling van eval(), hoewel ik het eens ben met degene die zeggen dat het in 99% van de gevallen erop wijst dat je code niet goed in elkaar zit. Maar mijn grootste probleem is het veiligheidsoogpunt. Kans op XSS e.d. vergroot je enorm wanneer je eval gaat invoegen. Daar zul je dan dus heel zorgvuldig mee om moeten gaan. Dat doet mij liever kiezen voor een andere manier, indien het anders kan

[T-MOB]

r0bert schreef op maandag 14 april 2008 @ 19:50:
Ik snap de bedoeling van eval(), hoewel ik het eens ben met degene die zeggen dat het in 99% van de gevallen erop wijst dat je code niet goed in elkaar zit. Maar mijn grootste probleem is het veiligheidsoogpunt. Kans op XSS e.d. vergroot je enorm wanneer je eval gaat invoegen. Daar zul je dan dus heel zorgvuldig mee om moeten gaan. Dat doet mij liever kiezen voor een andere manier, indien het anders kan

En hoe is je eigen eval()-implementatie dan veiliger dan eval() zelf?

[r0bert]

T-MOB schreef op maandag 14 april 2008 @ 20:16:
[...]

En hoe is je eigen eval()-implementatie dan veiliger dan eval() zelf?

Daar heb je zeker gelijk in! Dat maakt geen drol uit.

[ Voor 5% gewijzigd door r0bert op 14-04-2008 21:03 ]