Het XMLHTTPRequest object - het object zijn parame

Je hebt nu een leuk object, maar dat object heeft echt geen flauw idee wat het moet doen. Het is er gewoon, als een zombie. Dus kleden we het wat aan.

De eerste parameter (string), in mijn voorbeeld ‘GET’ kan ‘GET’ of ‘POST’ zijn. Ik neem aan dat het verschil wel bekend is. GET geeft zijn parameters via de url mee, POST via de body van de aanvraag.

Mijn tweede parameter, ‘pagina.php’, is de url die aangevraagd moet worden. Hier kan je ook nog standaard GET-parameters aan toevoegen, zoals bekend.

Derde parameter (boonlean) is de keuze of we een synchroon of een asynchroon vraagje willen stellen. Zet je deze op ‘false’, dan zal je pagina bevriezen waneer de aanvraag wordt uitgevoerd. Of dat nou echt is wat we willen...

de open()-functie doet niets anders dan parameters instellen. Er wordt nog geen data verzonden, en is nog niets in gang gezet!

Okee, nu weten we welke pagina we willen hebben, en op wat voor manier. Maar wat moet er gebeuren met het antwoord?



onreadystatechange is een mooi voorbeeld van een andere manier van events gebruiken. Waneer ons object naar een andere fase van de aanvraag springt, moet deze functie worden uitgevoerd. In mijn voorbeeld maak ik gebruik van een naamloze functie, die direct aan het event wordt geplakt. Je kan function(){ ook vervangen door bijvoorbeeld ‘geefOverbodigeInformatie’ uit mijn event(extra)-voorbeeld.

Ik denk dat je via addEvent() (weer uit mijn event-voorbeeld) ook dit event kan uitbuiten, maar dat heb ik nog nooit geprobeerd, en deze methode lijkt mij onderweg ook handiger.
Dan komen we meteen bij mijn if-lus. Deze kijkt in welke fase mijn object dan wel ooit niet bezig is.

Er zijn 4 fasen.

Vanaf fase 3 zou je in principe de binnengetrokken data kunnen gaan gebruiken, maar waarschijnlijk is de afhandeling sneller dan het ophalen, en dan loopt het zootje vast. Niet doen dus, altijd wachten op fase 4.

Houd er rekening mee dat deze functie pas uitgevoerd wordt nadat de aanvraag dus gestart is, en dat is nog steeds niet het geval. Ik ga mijn cliff-hanger niet nu al verraden.
En we hebben data, en wel in het object. En dat gaan we eruit halen, muhaha!

En dan zit er in onze div het antwoord van de aanvraag.

Als alternatief kan je responseXML gebruiken, maar daar kom ik op terug in de pagina’s over alternatieve data-formaten.

We kunnen nog wat meer parameters meesturen, waar we later geen spijt van zullen krijgen:

Ik stuur nog een header mee om caching te voorkomen. Als alternatief kan je je url nooit hetzelfde laten worden, door bijvoorbeeld een timestamp als parameter mee te sturen. Ik stuur ook nog een header mee waaraan ik de aanvraag van mijn object straks in mijn script aan terug kan herkennen. Later wordt wel duidelijk waarom ik dat zou willen.

« Lees de omschrijving en reacties