[AJAX] Synchronous XMLHttpRequest deprecated verklaard.

[Arcane Apex]

Als developer maak ik veelvuldig gebruik van AJAX in de websites waar ik aan werk, oftewel een Asynchronous XMLHttpRequest.

Nu is het ook mogelijk om een Synchronous XMLHttpRequest te maken, het zogenaamde SJAX. Dit kan in sommige code-situaties voordelen hebben t.o.v. AJAX, maar de officiele organisaties die over de Javascript- en de Webstandaarden gaan hebben besloten om Synchronous XMLHttpRequest deprecated te verklaren.

De reden hiervoor, zegt men, is omdat het in veel situaties de standaard manier breekt waarop gebruikers met browsers omgaan.

Okay, goed en wel. De nieuwste browserversies laten developers dit op tijd weten door alvast waarschuwingen te geven in de Javascript console voor developers. Synchronous XMLHttpRequest gaat dus verdwijnen. Deprecatie is meedogenloos voor developers, dus het is adapt or die.

Maar nu is het volgende het geval. Soms is een SJAX functie van kritiek belang voor het functioneren van een website. Dit is ook het geval voor een website waar ik voor ontwikkel.

Wat ik tot nu toe heb gedaan is om de volgende betreffende functie proberen om te vormen naar een AJAX functie in plaats van een SJAX functie. Het verschil om dit te doen is miniem, maar het breekt de gereturnde output compleet.

Wanneer ik de functie omvorm van SJAX naar AJAX, dan wordt de output ineens 'null'. En aangezien deze functie veelvuldig gebruikt wordt voor vele elementen in de website, is het van belang dat ik de gereturnde output exact hetzelfde houd wanneer ik de functie herschrijf van SJAX naar AJAX.

code:

//SJAX function: get the content of an xml file and store it in XML DOM. 

function getXML_file(pathToFileString) {
    

    if (window.XMLHttpRequest)
    {
        myRequestObject = new XMLHttpRequest();
    }
    else if (window.ActiveXObject) 
    {
        try
        {
            myRequestObject = new ActiveXObject("Msxml2.XMLHTTP");
        }
        catch (e)
        {
            try
            {
                myRequestObject = new ActiveXObject("Microsoft.XMLHTTP");
            } 
            catch (e) {}
        }
    }

    myRequestObject.open("GET", pathToFileString, false);   
    myRequestObject.send(null);

    //Set and return the content as XML DOM
    xmlDoc = myRequestObject.responseXML;

    return xmlDoc;
}

Okay, dat is dus de SJAX versie van de functie. En om deze om te vormen naar een AJAX functie dient enkel en alleen "false" veranderd te worden naar "true".

Het probleem hierbij is dat dit de gereturnde output breekt. Ik krijg dus als output dan null.

Wat zowiezo zal moeten gebeuren, is dat die waarde op "true" gezet moet worden, want dat is AJAX. "false" zal in de toekomst niet meer geaccepteerd worden door browsers, want dat is het deprecated SJAX. (Synchronous XMLHttpRequest)

Aangezien ik vooruitloop op de zaken is er nog maar zeer weinig informatie te vinden online over hoe je een Synchronous request om kan scripten naar een Asynchronous zonder dat dit de output breekt. Informatie hierover is vooralsnog schaars. Waarschijnlijk zal dit veranderen wanneer browsers SJAX daadwerkelijk ook niet meer ondersteunen, maar het is beter om nu alvast niet achterover te gaan zitten en te gaan wachten tot de site breekt in browser na browser.

In a nutshell, ik zal het probleem moeten oplossen.

De Synchronous XMLHttpRequest zal moeten worden omgevormd naar een Asynchronous XMLHttpRequest zonder dat de gereturnde output verandert.

En dit dient tevens cross-browser te werken.

Mijn vraag is, hoe kan ik dat doen? Ik gebruik geen jQuery of JSON, maar puur Javascript/AJAX, dus ik zoek een oplossing zonder jQuery en JSON.

[Nvidiot]

Je zult met een callback functie moeten gaan werken. Die functie geef je mee aan het XMLHttpRequest en wordt aangeroepen wanneer de data binnen is. Zie het voorbeeld hier: https://developer.mozilla...uest/Using_XMLHttpRequest

JavaScript:

function reqListener () {
  console.log(this.responseText);
}

var oReq = new XMLHttpRequest();
oReq.onload = reqListener;
oReq.open("get", "yourFile.txt", true);
oReq.send();

De reqListener wordt aangeroepen zodra de data binnen is. Op die plek kun je dan er iets mee doen (het in de DOM hangen op de juiste plek, etc)

[Arcane Apex]

Hoi, bedankt Nvidiot.

Dit is wat ik nu heb, maar de return value van de AJAX functie is nog steeds null. Maar ik kan in de javascript developer console zien dat de inhoud van het XML-bestand getoond wordt, dus het lijkt een stap voorwaarts te zijn.

Aangezien deze functie in vele andere functies gebruikt wordt, is het van belang dat de return value van de functie exact hetzelfde blijft als voorheen.

code:

//AJAX function: get the content of an xml file and store it in XML DOM. 

function getXML_file(pathToFileString) {
    

    if (window.XMLHttpRequest)
    {
        myRequestObject = new XMLHttpRequest();
    }
    else if (window.ActiveXObject) 
    {
        try
        {
            myRequestObject = new ActiveXObject("Msxml2.XMLHTTP");
        }
        catch (e)
        {
            try
            {
                myRequestObject = new ActiveXObject("Microsoft.XMLHTTP");
            } 
            catch (e) {}
        }
    }


    function reqListener(){
        console.log(this.responseXML);
    }

     
    myRequestObject.onload = reqListener;   
    myRequestObject.open("GET", pathToFileString, false);
    myRequestObject.send(null);

    //Set and return the content as XML DOM
    xmlDoc = myRequestObject.responseXML;

    return xmlDoc;
}

[ Voor 5% gewijzigd door Arcane Apex op 26-02-2015 00:04 ]

[gekkie]

Ipv een callback .. na je asynchrone request een blocking while loop maken die test en wacht op de onreadystatechange .. uitlezen en return ?

[azerty]

Arcane Apex schreef op donderdag 26 februari 2015 @ 00:00:
Hoi, bedankt Nvidiot.

Dit is wat ik nu heb, maar de return value van de AJAX functie is nog steeds null. Maar ik kan in de javascript developer console zien dat de inhoud van het XML-bestand getoond wordt, dus het lijkt een stap voorwaarts te zijn.

Aangezien deze functie in vele andere functies gebruikt wordt, is het van belang dat de return value van de functie exact hetzelfde blijft als voorheen.

code:

//AJAX function: get the content of an xml file and store it in XML DOM. 

function getXML_file(pathToFileString) {
    

    if (window.XMLHttpRequest)
    {
        myRequestObject = new XMLHttpRequest();
    }
    else if (window.ActiveXObject) 
    {
        try
        {
            myRequestObject = new ActiveXObject("Msxml2.XMLHTTP");
        }
        catch (e)
        {
            try
            {
                myRequestObject = new ActiveXObject("Microsoft.XMLHTTP");
            } 
            catch (e) {}
        }
    }


    function reqListener(){
        console.log(this.responseXML);
    }

     
    myRequestObject.onload = reqListener;   
    myRequestObject.open("GET", pathToFileString, false);
    myRequestObject.send(null);

    //Set and return the content as XML DOM
    xmlDoc = myRequestObject.responseXML;

    return xmlDoc;
}

Natuurlijk dat je waarde null is, de javascript gaat onmiddelijk na het initialiseren van de AJAX call verder met je code en returnt de null value. Het is pas in je reqListener, als de myRequestObject.readyState 4 is en de req.status 200 (al is dit laatste niet noodzakelijk), je je myRequestObject.responseXML niet null zal zijn (zoals je in je console.log ook kunt zien).

Als je je code niet kunt herschrijven, is (imho) de enige optie om na je send een while(true) loop te doen waar je slaapt zolang je reqListener de waarde niet terugggegeven heeft. Dit is echter geen al te nette oplossing. Beter zou zijn om aan je getXMLFile een parameter mee te geven met de locatie waar je je xml wilt opslaan (bijvoorbeeld).

Edit: spuit11, gekkie heeft gelijk idee

[Arcane Apex]

gekkie schreef op donderdag 26 februari 2015 @ 00:11:
Ipv een callback .. na je asynchrone request een blocking while loop maken die test en wacht op de onreadystatechange .. uitlezen en return ?

Dat klinkt ook als een mogelijke oplossing. Ik las namelijk over een soortgelijke oplossing op een ander forum van iemand die over hetzelfde probleem postte. Er werden daar alleen geen codevoorbeelden van gegeven, dus vraag ik me af hoe ik dat precies zou moeten implementeren in de functie die ik postte.

[ Voor 4% gewijzigd door Arcane Apex op 26-02-2015 00:19 ]

[gekkie]

wsitedesign schreef op donderdag 26 februari 2015 @ 00:15:
[...]
Edit: spuit11, gekkie heeft gelijk idee

Niet al te ver uitwerken gaf me een advantage

En ik verwacht dat onder de motorkap van je browser die synchrone versie ook na genoeg letterlijk zo in elkaar zal zitten (en dus een soort blocking wrapper om de asynchrone versie is)

En inderdaad is de aanvullende vraag .. waarom wil je het persé niet asynchroon maken ?
(als je connectie beroerd is en je request lang duurt dan freezed momenteel je UI)

[ Voor 17% gewijzigd door gekkie op 26-02-2015 00:21 ]

[.oisyn]

De vraag is alleen of dat object wel geüpdatet wordt terwijl je in je loop zit. Het mag dan wel asynchroon zijn, dat wil niet zeggen dat de boel ook thread safe is. Er is maar 1 javascript thread en events worden pas uitgevoerd op het moment dat de boel idlet.

[Arcane Apex]

gekkie schreef op donderdag 26 februari 2015 @ 00:19:
[...]
En inderdaad is de aanvullende vraag .. waarom wil je het persé niet asynchroon maken ?
(als je connectie beroerd is en je request lang duurt dan freezed momenteel je UI)

Ik wilde het wel asynchroon maken, maar de enige manier waarop ik de correcte return output kreeg van de functie was wanneer ik het synchroon maakte. Elke keer als ik probeer(de) er een asynchrone AJAX functie van te maken, dan werd de return value null.

En dat brak dus grote delen van de website. Die return value blijkt cruciaal te zijn, dus schreef ik de functie op basis van wat werkte. En lange tijd was dat prima, totdat men aangaf synchrone requests in de toekomst niet meer te ondersteunen.

Het was een kwestie van roeien met de spanen die ik had.

Als ik wist hoe ik de functie het optimaal asynchroon zou kunnen schrijven, terwijl de return output gelijk blijft, dan had ik dat graag gedaan.

[Arcane Apex]

.oisyn schreef op donderdag 26 februari 2015 @ 00:26:
De vraag is alleen of dat object wel geüpdatet wordt terwijl je in je loop zit. Het mag dan wel asynchroon zijn, dat wil niet zeggen dat de boel ook thread safe is. Er is maar 1 javascript thread en events worden pas uitgevoerd op het moment dat de boel idlet.

Goed punt. Ook dat speelt een rol.

[ Voor 3% gewijzigd door Arcane Apex op 26-02-2015 00:32 ]

[Gomez12]

Arcane Apex schreef op donderdag 26 februari 2015 @ 00:16:
[...]
Dat klinkt ook als een mogelijke oplossing. Ik las namelijk over een soortgelijke oplossing op een ander forum van iemand die over hetzelfde probleem postte. Er werden daar alleen geen codevoorbeelden van gegeven, dus vraag ik me af hoe ik dat precies zou moeten implementeren in de functie die ik postte.

In de basis (ik zou het niet doen, maar het volstaat) zou je ook een variabele kunnen initialiseren op een waarde, dan kan je met een ajax-request de return waarde in die variabele stoppen en je while-loop laat je dan gewoon loopen zolang je variabele de initiele waarde heeft (bij een returning ajax-call verandert je variabele en vlieg je dus uit je while-loop)

Maar wat is de use-case precies dat je een sjax nodig hebt? Want persoonlijk zou ik in zo'n geval eerder gaan voor een modal-spinner die je over je web-page heenlegt direct na verzenden en dat je in je listener de modal-spinner weer uitzet. Dan blokkeer je alle user-input op de web-page maar ga je niet cpu-cycles verspillen aan onnodige loops.

.oisyn schreef op donderdag 26 februari 2015 @ 00:26:
De vraag is alleen of dat object wel geüpdatet wordt terwijl je in je loop zit. Het mag dan wel asynchroon zijn, dat wil niet zeggen dat de boel ook thread safe is. Er is maar 1 javascript thread en events worden pas uitgevoerd op het moment dat de boel idlet.

Dan maak je geen while loop, maar maak je bijv een eeuwigdurende settimeout-constructie die blijft herhalen totdat er data is.

In principe wil je hier sowieso geen while-loops voor gebruiken aangezien je daarmee je hele computer belast ipv dat je daadwerkelijk zit te wachten.

[gekkie]

.oisyn schreef op donderdag 26 februari 2015 @ 00:26:
De vraag is alleen of dat object wel geüpdatet wordt terwijl je in je loop zit. Het mag dan wel asynchroon zijn, dat wil niet zeggen dat de boel ook thread safe is. Er is maar 1 javascript thread en events worden pas uitgevoerd op het moment dat de boel idlet.

Creatieve recursieve timer constructie ?
(neem aan dat als je niet echt asynchroon gaan webworkers ook wel niet zullen mogen)

Maar goed ik zou gewoon vrolijk een lightweight javascript library erin stoppen.

*shoot* nou leg ik het weer af tegen gomez :-p

[ Voor 4% gewijzigd door gekkie op 26-02-2015 00:35 ]

[.oisyn]

Gomez12 schreef op donderdag 26 februari 2015 @ 00:32:
In de basis (ik zou het niet doen, maar het volstaat) zou je ook een variabele kunnen initialiseren op een waarde, dan kan je met een ajax-request de return waarde in die variabele stoppen en je while-loop laat je dan gewoon loopen zolang je variabele de initiele waarde heeft (bij een returning ajax-call verandert je variabele en vlieg je dus uit je while-loop)

Gaat niet werken, die callback wordt niet uitgevoerd terwijl je in de while loop zit. Nogmaals, javascript is (in de browser) niet multithreaded.

Dan maak je geen while loop, maar maak je bijv een eeuwigdurende settimeout-constructie die blijft herhalen totdat er data is.

Wat ben je er dan mee opgeschoten? Kun je beter gewoon die callback gebruiken . Het feit dat je dat niet wilt is omdat je de boel gewoon wil afhandelen in de functie waar je op dat moment in zit. Dat kan met jouw gekunstel net zo goed niet

In principe wil je hier sowieso geen while-loops voor gebruiken aangezien je daarmee je hele computer belast ipv dat je daadwerkelijk zit te wachten.

Dat hangt er maar net vanaf wat je ín die while loop doet . Maar idd, javascript heeft geen sleep of yield oid.

[ Voor 25% gewijzigd door .oisyn op 26-02-2015 00:42 ]

[Gomez12]

.oisyn schreef op donderdag 26 februari 2015 @ 00:39:
[...]

Wat ben je er dan mee opgeschoten? Kun je beter gewoon die callback gebruiken . Het feit dat je dat niet wilt is omdat je de boel gewoon wil afhandelen in de functie waar je op dat moment in zit. Dat kan met jouw gekunstel net zo goed niet

Ehm, praktisch gezien niets

Het was meer een doorwerkende denkfout beginnend met while-loop (wat ik al opzich al afraad maar wel een directe "oplossing" zou zijn) en daarna jouw bezwaar tegen een while-loop lezen en dan daar weer omheen te willen werken (en ondertussen het beginpunt vergeten zijn)

[Arcane Apex]

Gomez12 schreef op donderdag 26 februari 2015 @ 00:32:
[...]
Maar wat is de use-case precies dat je een sjax nodig hebt?
[...]

De SJAX functie heeft een pad naar een XML bestand als input. Het XML-bestand wordt vervolgens ingelezen met behulp van een synchroon request. De output van de functie is dus pure XML. En die output wordt vervolgens door vele andere javascript functies gebruikt die elementen op de website updaten zonder de browser te hoeven verversen.

De reden dat er een synchroon request gebruikt werd is omdat dat wel werkte en wanneer er een asynchroon request gebruikt werd, dat dat de output keer op keer brak. (werd null)

Het kan best zo zijn dat er betere manieren zijn om dit te doen, wellicht zelfs zonder AJAX, maar andere manieren heb ik tot dusver niet kunnen vinden.

[Arcane Apex]

Maar ik denk dat de code van Nvidiot me al wel op de goede weg zette, want ik kan in de console nu de output zien van het XML-bestand.

Maar zoals wsitedesign zei, heb ik de code van Nvidiot gewoonweg verkeerd geimplementeerd.

Ik heb dus het gevoel dat ik hiermee warm zit bij een oplossing. Ik vermoed dat het een kwestie is van een kleine aanpassing aan mijn code.

De XML output in de console is er in ieder geval al wel. Maar die output moet juist de return value zijn van de functie.

[Juup]

Kijk naar de readyState van je XHR:
http://www.tizag.com/ajaxTutorial/ajaxxmlhttprequest.php

[Caballeros]

Is het niet handiger om die xml serverside in je html te injecteren.

[.oisyn]

Gomez12 schreef op donderdag 26 februari 2015 @ 00:42:
Het was meer een doorwerkende denkfout beginnend met while-loop (wat ik al opzich al afraad maar wel een directe "oplossing" zou zijn)

Je hebt m'n edit denk ik gemist, maar nee, dat is geen oplossing. Gaat simpelweg niet werken. Javascript in de browser is singlethreaded. De XHR callback wordt pas uitgevoerd nadat de functie op de bodem van de stack is gereturnd. Waarschijnlijk wordt de readyState niet eens geüpdatet tijdens de while loop, want dat zou impliceren dat access naar het XHR object thread-safe moet zijn, wat verder helemaal geen requirement is.

[ Voor 24% gewijzigd door .oisyn op 26-02-2015 11:51 ]

[Arcane Apex]

Okay ik ben een stap verder. De code die ik nu heb is alsvolgt:

code:

//AJAX function: get the content of an xml file and store it in XML DOM. 

    function getXML_file(pathToFileString) {
    

    if (window.XMLHttpRequest)
    {
        myRequestObject = new XMLHttpRequest();
    }
    else if (window.ActiveXObject) 
    {
        try
        {
            myRequestObject = new ActiveXObject("Msxml2.XMLHTTP");
        }
        catch (e)
        {
            try
            {
                myRequestObject = new ActiveXObject("Microsoft.XMLHTTP");
            } 
            catch (e) {}
        }
    }

    myRequestObject.onreadystatechange = function()
        {
            if(myRequestObject.readyState == 4)
            {
                // sets and returns the content as XML DOM
                xmlDoc = myRequestObject.responseXML;               
                
                return xmlDoc;
            } 
        };

   
    myRequestObject.open("GET", pathToFileString, true);
    myRequestObject.send(null);

}

Dit geeft de juiste return value wanneer ik de output van de functie log naar de console van de browser, maar er is een probleem.

En dat probleem is dat wanneer een andere Javascript functie deze AJAX functie aanroept, dat deze de return value direct probeert te gebruiken, nog voordat de readyState van de request status 4 heeft bereikt. Ik krijg dan een error die zegt de return value die gebruikt wordt "undefined" is.

Andere functies proberen dus de output van deze AJAX functie al te gebruiken voordat het XML bestand klaar is met laden.

Een stap voorwaarts is nu dus gezet, maar ik wil ook graag dit laatste probleem oplossen.

[.oisyn]

Wat denk je dat regel 26 doet dan? Je maakt een callback die de xmlDoc returnt, maar aan wie returnt hij die doc? Aan degene die de callback aanroept, oftewel ergens in de browser core code die de afhandeling van de XHR doet.

Je moet het probleem op een hoger niveau aanpakken. Degene die getXML_file aanroept zou eigenlijk zelf een callback mee moeten geven, zodat je in de XHR callback die callback aan kunt roepen met het juiste XML document.

[Arcane Apex]

.oisyn schreef op donderdag 26 februari 2015 @ 16:07:
Wat denk je dat regel 26 doet dan? Je maakt een callback die de xmlDoc returnt, maar aan wie returnt hij die doc? Aan degene die de callback aanroept, oftewel ergens in de browser core code die de afhandeling van de XHR doet.

Je moet het probleem op een hoger niveau aanpakken. Degene die getXML_file aanroept zou eigenlijk zelf een callback mee moeten geven, zodat je in de XHR callback die callback aan kunt roepen met het juiste XML document.

Dat is een heel goed idee.

Ga ik meteen even proberen.

[Arcane Apex]

On second thought, ik weet niet of dat wel een elegante oplossing is, want dan zou ik elke functie die deze functie aanroept moeten wijzigen.

[Caelorum]

Elegant misschien niet, maar wel de enige die je nog kan doen. Soms moet je helaas wat werk verzetten.

[ Voor 24% gewijzigd door Caelorum op 26-02-2015 16:50 ]

[Arcane Apex]

Wat moet, dat moet. Dus ik ga het doen. Maar graag zou ik nog wel een eventuele oplossing willen vinden om het op een elegante manier op te lossen.

Ik ga er zowiezo al mee aan de slag. Het zal wel moeten, want ik kan niet met deprecated code blijven zitten. Dat is een probleem dat zowiezo uiteindelijk de kop op zal steken.

[Arcane Apex]

Okay, ik heb het werkend gekregen. Oisyn gaf inderdaad het laatste stukje van de puzzel. Het werkt nu in ieder geval. Nu rest nog het werk om al die functies aan te passen. C'est la vie.

Een bijkomend voordeel is nu dat het aangepaste deel van de website veel sneller reageert. De code is nu dus merkbaar sneller ten opzichte van de SJAX oplossing. Ik krijg verder ook geen errors of warnings meer van deprecated code.

Good stuff guys.

[gekkie]

Arcane Apex schreef op donderdag 26 februari 2015 @ 17:20:
Okay, ik heb het werkend gekregen. Oisyn gaf inderdaad het laatste stukje van de puzzel. Het werkt nu in ieder geval. Nu rest nog het werk om al die functies aan te passen. C'est la vie.

Een bijkomend voordeel is nu dat het aangepaste deel van de website veel sneller reageert. De code is nu dus merkbaar sneller ten opzichte van de SJAX oplossing. Ik krijg verder ook geen errors of warnings meer van deprecated code.

Good stuff guys.

Tsja voordeel van asynchroon heh

[Caelorum]

Arcane Apex schreef op donderdag 26 februari 2015 @ 16:55:
Wat moet, dat moet. Dus ik ga het doen. Maar graag zou ik nog wel een eventuele oplossing willen vinden om het op een elegante manier op te lossen]...]

Asynchrone requests *zijn* de elegante manier om jouw probleem ( data ophalen en resp. UI houden/minder cpu cycles gebruiken) op te lossen ^^

[R4gnax]

Arcane Apex schreef op donderdag 26 februari 2015 @ 16:55:
Wat moet, dat moet. Dus ik ga het doen. Maar graag zou ik nog wel een eventuele oplossing willen vinden om het op een elegante manier op te lossen.

https://developer.mozilla...ce/Global_Objects/Promise