[PHP/JS] AJAX trucjes

[XWB]

Ik val maar meteen met de deur in huis. Ik heb twee selectboxjes. De eerste bevat locaties en de tweede bevat lokalen. Door een waarde uit de eerste te selecteren wordt een query opgebouwd welke alle lokalen van die geselecteerde locatie ophaald. Daar had ik een werkende code voor, echter wil ik het nu met ajax hermaken. Ik heb verschillende online tutorials gevold, en krijg wel een voorbeeld werkend met textfields, maar niet met een select.

De code:

HTML:

<select style="width: 150px;" name="locatie" id="locatie" onchange="ZoekLokalen(this.value)">
<option value="1">Locatie 1</option>
<option value="2">Locatie 2</option>
<option value="3">Locatie 3</option>
</select>

<select style="width: 150px;" name="lokalen" id="lokalen">
</select>

JavaScript:

var url = "test.php?para=";

    function handleHttpResponse() 
    { 
        if (http.readyState == 4) 
        {
            var result = http.responseText.split(",");
            var optionText = result[0];
            var optionValue = result[1];
        } 
    }

    function ZoekLokalen(locatie) 
    {
        http.open("GET", url+locatie, true); 
        http.onreadystatechange = handleHttpResponse; 
        http.send(null);
    }

    function getHTTPObject() 
    {
        var xmlhttp;
        
        if (window.XMLHttpRequest)
        {
            xmlhttp = new XMLHttpRequest();
        }
        else if (window.ActiveXObject)
        {
            xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
        }

        return xmlhttp;
    }

    var http = getHTTPObject();

test.php

PHP:

require_once('../includes/classes.php');
$db = new dbase();

$locatie = $_GET['para'];

$db->query('SELECT * 
            FROM lokalen
            WHERE vestiging = "' . $locatie . '" 
                  AND pc_aanwezig = "1"
            ORDER BY lokaal_nr ASC');

while($result = $db->fetch_array())
{
    echo $result['lokaal_id'] . ',' . $result['lokaal_nr'];
}

- De resultaten komen binnen met http.responseText. Het resultaat komt dus op 1 regel binnen. Vraag is, hoe haal ik nu de verschillende resultaten uit die regel
- De options daarna aanmaken kan met new option, maar daarvoor moet ik weten hoeveel resultaten er zijn. De options moeten dan in de select lokalen komen.

[ Voor 10% gewijzigd door XWB op 13-01-2006 11:35 ]

[MTWZZ]

string.split?
http://javascriptkit.com/javatutors/string4.shtml

[XWB]

JavaScript:

var result = http.responseText.split(",");
var optionText = result[0];
var optionValue = result[1];

Zoiets werkt ja, voor 1 resultaat. Ik kan met een lus het aantal options wel opbouwen, maar daarom moet ik weten hoeveer resultaten er zijn. Misschien kan ik het totaal in het begin van de string meegeven en in de js code de eerste waarde eruit halen?

[Erkens]

Zelf zou ik ook daadwerkelijk XML als output van mijn PHP doen, dan hoef je ook niet moeilijk te doen met splitten en weten hoeveel results er zijn. Die XML kan je dan via DOM in je javascript lezen en bijna rechtstreeks naar je DOM tree van je HTML wegschrijven

[LuCarD]

Hacku schreef op vrijdag 13 januari 2006 @ 11:41:

JavaScript:

var result = http.responseText.split(",");
var optionText = result[0];
var optionValue = result[1];

Zoiets werkt ja, voor 1 resultaat. Ik kan met een lus het aantal options wel opbouwen, maar daarom moet ik weten hoeveer resultaten er zijn. Misschien kan ik het totaal in het begin van de string meegeven en in de js code de eerste waarde eruit halen?

result.length dan kan je zien hoeveel elementen je hebt. Deel door 2 dan weet je hoeveel options je moet bouwen.

[crisp]

Eea heeft natuurlijk ook te maken met je output format. Zoals Erkens al zegt zou je kunnen opteren om echt XML terug te geven; alternatieven zijn inderdaad plain-text (delimited), JSON of een andere manier van serializen (zelf gebruik ik regelmatig een JS-implementatie van PHP's serialize/unserialize).

En dit hoort idd in Webdesign & Graphics

[Not Pingu]

XML is voor zo'n simpel dataformaat niet nodig imho. Gewoon in test.php aan het eind van elk resultaat iets toevoegen waar je op kunt splitten. Dus:

code:

echo $result['lokaal_id'] . ',' . $result['lokaal_nr'] . '|';

In javascript split je dan eerst op | om alle resultaten te krijgen, vervolgens loop je die array door en split je elk element op , om de ID en het nummer te krijgen.

Dat is makkelijker dan XML moeten doorzoeken en kent een stuk minder overhead.

[ Voor 17% gewijzigd door Not Pingu op 13-01-2006 12:15 ]

[djluc]

Je kunt ook gewoon zo'n standaard AJAX library gebruiken. Bijvoorbeeld: http://blog.joshuaeichorn...-hello-world-with-jpspan/ Die nemen dit soort problemen allemaal weg. Je stuurt een request en ontvangt weer een array, super simpel.

[Erkens]

Gunp01nt schreef op vrijdag 13 januari 2006 @ 12:14:

code:

echo $result['lokaal_id'] . ',' . $result['lokaal_nr'] . '|';

moet je wel opletten dat er geen ',' of '|' in je content staat...

Dat is makkelijker dan XML moeten doorzoeken en kent een stuk minder overhead.

Overhead valt opzich wel mee, je hoeft geen ingewikkelde XML te bouwen. Daarnaast is die overhead sowieso te verwaarlozen als je iets als compressie toepast.
Verder hoef je de XML niet te doorzoeken, dat doet DOM voor je

[Sappie]

Of gewoon innerHTML gebruiken en in de data die je verzendt gewoon de option elementen reeds neerkwakken.

[djluc]

Sappie schreef op vrijdag 13 januari 2006 @ 12:39:
Of gewoon innerHTML gebruiken en in de data die je verzendt gewoon de option elementen reeds neerkwakken.

Dat kan ook maar is natuurlijk niet zo'n mooie oplossing

[Sappie]

das snel maar leg mij eens uit waarom dat niet zo'n mooie oplossing is

[MTWZZ]

Omdat als je met DOM werkt je pagina geldig blijft en er geen gekke dingen gaan gebeuren.
Stel dat jouw server een 404 of 500 uitpoept dan gaan er gekke dingen met jouw select gebeuren.
Als je netjes met DOM aan de slag gaat krijg je een error (die je natuurlijk wel goed moet opvangen) en kun je op basis daar van de goeie dingen doen.

[xtra]

Sappie schreef op vrijdag 13 januari 2006 @ 12:40:
das snel maar leg mij eens uit waarom dat niet zo'n mooie oplossing is

Omdat je dan je datalaag en presentatielaag gaat mixen. Als je volgende week dezelfde data op een andere manier wilt gebruiken moet je helemaal opnieuw gaan beginnen of de toegestuurde html alsnog gaan vertalen.

[Sappie]

MTWZZ schreef op vrijdag 13 januari 2006 @ 12:44:
Omdat als je met DOM werkt je pagina geldig blijft en er geen gekke dingen gaan gebeuren.
Stel dat jouw server een 404 of 500 uitpoept dan gaan er gekke dingen met jouw select gebeuren.
Als je netjes met DOM aan de slag gaat krijg je een error (die je natuurlijk wel goed moet opvangen) en kun je op basis daar van de goeie dingen doen.

Als je data gewoon valid html is is er natuurlijk niets aan de hand; en daar kun je uiteraard zelf voor zorgen

Voor wat betreft de 404 en 500 kun je op (in dit geval "http.") http.status checken, dus das ook geen probleem.

xtra schreef op vrijdag 13 januari 2006 @ 12:45:
Omdat je dan je datalaag en presentatielaag gaat mixen. Als je volgende week dezelfde data op een andere manier wilt gebruiken moet je helemaal opnieuw gaan beginnen of de toegestuurde html alsnog gaan vertalen.

Een beetje presentatie valt nu binnen de datalaag idd. Toch denk ik dat dit in deze simpele situatie niet opweegt tegen de voordelen van het gebruik van innerhtml.

- Je hoeft geen XML file te parsen
- Als gevolg daarvan is je javascript korter / kleiner
- Bovendien is het gebruik van innerHTML over het algemeen sneller dan het gebruik van DOM scripting.

Ook lijkt het me ook onwaarschijnlijk dat de data in dit geval anders gebruikt gaat worden.

[ Voor 90% gewijzigd door Sappie op 13-01-2006 12:59 ]

[Erkens]

Sappie schreef op vrijdag 13 januari 2006 @ 12:48:
Als je data gewoon valid html is is er natuurlijk niets aan de hand; en daar kun je uiteraard zelf voor zorgen

Voor wat betreft de 404 en 500 kun je op (in dit geval "http.") http.status checken, dus das ook geen probleem.

ooit gehoord van bijvoorbeeld een PHP error die naar de output gaat? (display_errors setting)
Wordt leuk in een select box

[Sappie]

Dan zorg je er maar voor dat je PHP geen errors bevat

[Erkens]

Sappie schreef op vrijdag 13 januari 2006 @ 12:57:
Dan zorg je er maar voor dat je PHP geen errors bevat

True elke applicatie is bug vrij
Maar je moet ook dergelijke fouten opvangen aan de client kant, immers een upgrade van PHP en 9 van de 10x gaan je scripts kapot
Maar dit zijn nog maar enkele dingen die fout kunnen gaan, gewoon de output in je innerHtml knallen is geen goed idee imo.

[ Voor 4% gewijzigd door Erkens op 13-01-2006 13:02 ]

[crisp]

Erkens schreef op vrijdag 13 januari 2006 @ 13:01:
[...]

Maar dit zijn nog maar enkele dingen die fout kunnen gaan, gewoon de output in je innerHtml knallen is geen goed idee imo.

Ben ik het ook mee eens, en daarom ben ik ook voorstander van het gebruik van een serialized formaat of XML. Je unserialize-functie of XML parser kan dan eventuele fouten in de output ontdekken en daarop actie ondernemen.

JSON heeft daarom ook niet mijn voorkeur omdat dat normaliter lukraak door eval() heengegooid wordt.

[Sappie]

Erkens schreef op vrijdag 13 januari 2006 @ 13:01:
[...]

True elke applicatie is bug vrij
Maar je moet ook dergelijke fouten opvangen aan de client kant, immers een upgrade van PHP en 9 van de 10x gaan je scripts kapot
Maar dit zijn nog maar enkele dingen die fout kunnen gaan, gewoon de output in je innerHtml knallen is geen goed idee imo.

We hebben het hier wel over een erg simpele situatie. Ik zeg niet dat het gebruik van innerHTML in elke situatie de voorkeur geniet; ik zeg enkel dat ik niet in zie waarom het in deze specifieke (simpele) situatie niet een goed (misschien zelfs beter) alternatief is dan het gebruik van bijvoorbeeld DOM scripting.

hier nog een leuk stuk erover wat ik net vond: http://www.quirksmode.org...5/12/the_ajax_respon.html

[BasieP]

Erkens schreef op vrijdag 13 januari 2006 @ 13:01:
[...]

True elke applicatie is bug vrij
Maar je moet ook dergelijke fouten opvangen aan de client kant, immers een upgrade van PHP en 9 van de 10x gaan je scripts kapot
Maar dit zijn nog maar enkele dingen die fout kunnen gaan, gewoon de output in je innerHtml knallen is geen goed idee imo.

op het moment dat jij client side de serverside fouten gaat afvangen doe je denk ik ook iets niet goed.

na een upgrade van php werkt je code dan net zo hard nog niet, alleen ziet de gebruiker geen fouten (en zal jouw als maker dus ook minder feedback kunnen geven)

verder ben ik het er mee eens dat je niet zomaar alles letterlijk moet laten zien wat php uitpoept, maar in dit geval kan dat prima

[Erkens]

BasieP schreef op vrijdag 13 januari 2006 @ 13:06:
op het moment dat jij client side de serverside fouten gaat afvangen doe je denk ik ook iets niet goed.

na een upgrade van php werkt je code dan net zo hard nog niet, alleen ziet de gebruiker geen fouten (en zal jouw als maker dus ook minder feedback kunnen geven)

want als je de fout afvangt kan je geen duidelijke melding geven aan de gebruiker dat het stuk is

[BasieP]

Erkens schreef op vrijdag 13 januari 2006 @ 13:09:
[...]

want als je de fout afvangt kan je geen duidelijke melding geven aan de gebruiker dat het stuk is

tuurlijk wel, maar in veel gevallen erger ik me zelf juist aan dit soort dingen..

een regeltje text kan niet opgehaalt worden, en direct kapt je hele webapp met een grote 'FOUT' melding...
erg vervelend als de rest nog wel gewoon werkt

[Erkens]

BasieP schreef op vrijdag 13 januari 2006 @ 13:12:
[...]


tuurlijk wel, maar in veel gevallen erger ik me zelf juist aan dit soort dingen..

een regeltje text kan niet opgehaalt worden, en direct kapt je hele webapp met een grote 'FOUT' melding...
erg vervelend als de rest nog wel gewoon werkt

ehm, juist door goed gebruik van errorhandling kan je ervoor zorgen de de webapp _juist_ door blijft werken ondanks dat er iets fout gegaan is (tot op zekere hoogte natuurlijk).
Dat is nu juist het nut van errorhandling, als je je daar helemaal niet mee bezig houdt is de kans enorm groot dat het geheel niet meer werkt bij het eerste verkeerde bitje wat binnenkomt

[Peter]

Gebruikers hebben vaak een grotere hekel aan een nietsvertellende javascript error of allerlei beveligingswaarschuwingen in hun browsers, dan een net berichtje dat er iets fout is gegaan

[Not Pingu]

Erkens schreef op vrijdag 13 januari 2006 @ 13:09:
[...]

want als je de fout afvangt kan je geen duidelijke melding geven aan de gebruiker dat het stuk is

Meer om te voorkomen dat je onvolledige of verkeerd geformatteerde data gaat weergeven dan dat je de gebruiker op de hoogte wilt stellen van wat er fout is gegaan, lijkt me.

[Sappie]

Erkens schreef op vrijdag 13 januari 2006 @ 13:18:
[...]

ehm, juist door goed gebruik van errorhandling kan je ervoor zorgen de de webapp _juist_ door blijft werken ondanks dat er iets fout gegaan is (tot op zekere hoogte natuurlijk).
Dat is nu juist het nut van errorhandling, als je je daar helemaal niet mee bezig houdt is de kans enorm groot dat het geheel niet meer werkt bij het eerste verkeerde bitje wat binnenkomt

Aangenomen dat het simpele php script geen errors bevat, kan dus errorhandling worden geimplementeerd door middel van het checken van de status van de binnenkomende data. Is dit "200" dan kan je ervan uitgaan dat de data netjes verzonden en ontvangen is. Is dit iets anders dan kan je de gebruiker uiteraard een nette foutmelding voorschotelen

[ Voor 15% gewijzigd door Sappie op 13-01-2006 13:33 ]

[SchizoDuckie]

Ik ben eerlijk gezegd een groot voorstander van PHP + JSON, en ik ben nog totaal geen problemen tegengekomen qua PHP errors of wat dan ook.

De php errors hoor je netjes in je eigen code af te vangen, en te loggen, daar heeft de gebruiker imo weinig meer mee te maken dan een simpele melding.

In je javascript moet je JSON inderdaad weer terugzetten naar een object, en ik gebruik daar zelf eval() voor, maar er zijn ook speciale JSON parsers voor degenen die geen controle hebben over wat er heen en weer gestuurd wordt.

Het allergrootste bijkomende voordeel is dat je weinig rekening hoeft te houden met content-types, UTF-8 encodings, CDATA xml blokken, etc, iets wat voor veel applicaties (en developers) té veel tijd kost om helemaal van de grond af op te bouwen voor een simpele ajax applicatie waar hier en daar wat gegevens heen en weer gestuurd worden.

Ik gebruik trouwens momenteel Moo.Ajax, een briljant kort (1.3KB) scriptje van de makers van Moo.FX, met een aantal kleine aanpassingen zodat ik bijv. in 1x meerdere DIVS kan uploaden, en een scriptblok via php naar JSON output, en terug naar de client kan sturen.

Ik vind het hele poeha van eval() is vies, innerHTML is vies, en blabla eigenlijk een beetje zwaar overdreven. als je de innerHTML van een object netjes vervangt door goede code is er in geen enkele browser wat aan de hand, je kan gewoon met document.getElementByID (of $ ) een div opvragen die zojuist in je DOM geplaatst is, en daar mee doen wat je wil, en als je de hele zwik nog netjes in een Try / Catch block zet, heb je imo net zoveel kans dat er iets fout gaat met een XML library van tig duizend regels als met eval(), een for loopje en een simpel JSON object.

Het "jamaar, als je php dan upgrade" argument slaat ook kant noch wal lijkt me... je gaat niet zomaar even van een productie omgeving een PHP update draaien zonder eerst te testen wat er gebeurt.

Just my $0,50

[crisp]

SchizoDuckie schreef op vrijdag 13 januari 2006 @ 13:48:
In je javascript moet je JSON inderdaad weer terugzetten naar een object, en ik gebruik daar zelf eval() voor, maar er zijn ook speciale JSON parsers voor degenen die geen controle hebben over wat er heen en weer gestuurd wordt.

De JSON 'parser' die ik gezien heb is niets meer dan een check mbv een regular expression alvorens alsnog eval() uit te voeren

[SchizoDuckie]

crisp schreef op vrijdag 13 januari 2006 @ 14:17:
[...]

De JSON 'parser' die ik gezien heb is niets meer dan een check mbv een regular expression alvorens alsnog eval() uit te voeren

Klopt uiteraard, maar eval() is daar ook voor bedoeld. de parser is er alleen om te zorgen dat er geen fouten in voorkomen.
Parser zegt niet okee -> code niet uitvoeren ?

Ik blijf toch een beetje met het idee zitten van _waarom_ niet... Je weet als programmeur hoe je je code schrijft, je schrijft het állemaal in javascript, maar een eval() over een json object is dan weer te vies ?

Een andere oplossing die ik heb gezien trouwens is het aanmaken van een dynamische <script> tag en daartussen de JSON string plempen, maar dat vind ík dan weer viezer omdat je dan helemaal geen controle hebt over eventuele foutmeldingen.

[ Voor 37% gewijzigd door SchizoDuckie op 13-01-2006 14:30 ]

[crisp]

SchizoDuckie schreef op vrijdag 13 januari 2006 @ 14:27:
[...]


Klopt uiteraard, maar eval() is daar ook voor bedoeld. de parser is er alleen om te zorgen dat er geen fouten in voorkomen.
Parser zegt niet okee -> code niet uitvoeren ?

Ik noem dat geen parser maar een syntax-check

Nadeel van JSON / eval() is toch wel dat je serverside output al de naamgeving van je javascript variabele(n) dicteerd waardoor serverside script en clientside script niet geheel losstaand van elkaar zijn. Bij het gebruik van serialized data of XML kan je in je clientside script de data toekennen aan elke variabele die je wilt - je bent dan toch onafhankelijker.

[SchizoDuckie]

crisp schreef op vrijdag 13 januari 2006 @ 14:34:
[...]

Ik noem dat geen parser maar een syntax-check

Nadeel van JSON / eval() is toch wel dat je serverside output al de naamgeving van je javascript variabele(n) dicteerd waardoor serverside script en clientside script niet geheel losstaand van elkaar zijn.

Dat is alleen echt een nadeel als je hele rare truuken uit gaat halen imo. Je kan JSON ook zo doorlopen dat je variabele X op plaat Y neerzet.

Er valt voor allebei gewoon wat te zeggen. Als je erg complexe applicaties maakt moet je gewoon 'netjes' XML gebruiken, maar als je alleen hier en daar een update van een div doet n.a.v. een actie dan is JSON een erg simpele en binnen 5 minuten te impementeren optie

Overigens,MicroSoft's ajax-framework-to-be Atlas loopt ook op JSON voor zover ik weet

[ Voor 7% gewijzigd door SchizoDuckie op 13-01-2006 14:44 ]

[crisp]

SchizoDuckie schreef op vrijdag 13 januari 2006 @ 14:39:
[...]

True, JSON is makkelijk en snel te implementeren en is voor eenvoudige doeleinden vaak ook wel een geschikte keus. Ik hou echter toch vast aan mijn eigen methode die in feite net zo eenvoudig is (serverside bij gebruik van PHP zelfs eenvoudiger) als JSON maar wel iets meer flexibiliteit biedt

[SchizoDuckie]

crisp schreef op vrijdag 13 januari 2006 @ 14:49:
[...]
Ik hou echter toch vast aan mijn eigen methode die in feite net zo eenvoudig is (serverside bij gebruik van PHP zelfs eenvoudiger) als JSON

I dare ya...

PHP:

// PHP 5 ofcourse
$js = new jsObject();
$js->divnaam = '<strong>kwaak</strong>';
$js->anderedivnaam = '<em>Quack</em>';
$js->display(); // die()'t na serialisation

(die flexibiliteit moet je dan natuurlijk even niet meedenken )

[ Voor 16% gewijzigd door SchizoDuckie op 13-01-2006 14:56 ]

[crisp]

SchizoDuckie schreef op vrijdag 13 januari 2006 @ 14:53:
[...]


I dare ya...

PHP:

// PHP 5 ofcourse
$js = new jsObject();
$js->divnaam = '<strong>kwaak</strong>';
$js->anderedivnaam = '<em>Quack</em>';
$js->display(); // die()'t na serialisation

(die flexibiliteit moet je dan natuurlijk even niet meedenken )

PHP:

$js = array();
$js['divnaam'] = '<strong>kwaak</strong>';
$js['anderedivnaam'] = '<em>Quack</em>';
die(serialize($js));

[Peter]

PHP:

die( serialize( array(
    'divnaam' => '<strong>kwaak</strong>',
    'anderedivnaam' => '<em>Quack</em>' ) ) );

[SchizoDuckie]

Klinkt op zich heel erg leukmet serialize, maar JSON werkt niet met het zelfde serialization formaat als PHP... Dit gaat niet werken dus. Jammer, nice try

[Erkens]

crisp schreef op vrijdag 13 januari 2006 @ 11:55:
zelf gebruik ik regelmatig een JS-implementatie van PHP's serialize/unserialize.

[SchizoDuckie]

Erkens schreef op zaterdag 14 januari 2006 @ 11:17:
[...]

Ik heb even niets gezegd

[XWB]

Ik ben noob met XML, maar heb toch maar even geprobeerd. Echter gaat het fout door de meerdere <option>

XML:

<lijst>
<option value="15">001</option>
<option value="6">004</option>
</lijst>

Ik heb wel een werkende versie met innerHTML. Echter, het werkt alleen in Firefox, niet in IE. Ik weet waar het fout gaat, maar niet waarom:

JavaScript:

    function handleHttpResponse() 
    { 
        if (http.readyState == 4) 
        {
            if (http.status == 200)
            {
                //hier gaat het mis
                document.getElementById('lokaal').innerHTML = http.responseText;
            }
            else
            {
                document.getElementById('error').innerHTML = "Fout";
            }
        } 
    }  

(zelf gebruik ik regelmatig een JS-implementatie van PHP's serialize/unserialize)

En hoe gaat dat juist?

[Sappie]

met behulp van innerHTML pleur je dus de gehele inhoud van de responseText in je <select>. Uiteraard dienen daar slechts de <option> elementen in te staan. Dus <lijst> en </lijst> dien je dus weg te laten uit de aangeleverde data

[ Voor 10% gewijzigd door Sappie op 14-01-2006 13:08 ]

[XWB]

Weet ik, maar die oplossing met innerhtml was zonder xml output

Nou heb ik dit:

JavaScript:

    function handleHttpResponse() 
    { 
        if (http.readyState == 4) 
        {
            if (http.status == 200)
            {
                var result = http.responseXML.getElementsByTagName('optie');
                var aantal = result.length;
                
                for (var i=0; i < aantal; i++)
                {
                    var a = document.getElementById('lokaal'); //de select
                    var opt = document.createElement('option');
                    
                    opt.value = getNodeValue(result[i], 'waarde');
                    opt.text = getNodeValue(result[i], 'tekst');
                    
                    a.appendChild(opt);
                    
                    document.getElementById('lokaal').appendChild(a);
                }
            }
        } 
    }

    function getNodeValue(obj, tag)
    {
        return obj.getElementsByTagName(tag)[0].firstChild.nodeValue;
    }

code:

<lijst>
 <optie>
    <waarde>15</waarde>
    <tekst>001</tekst>
 </optie>
 <optie>
    <waarde>6</waarde>
    <tekst>004</tekst>
 </optie>
</lijst>

Er moet een fout in m'n for lus zitten want hij pakt enkel de eerste waarde. En bij een andere selectie moeten de vorige options weer verwijderd worden. Als iemand me verder kan helpen

[crisp]

Misschien kan je hier wat mee; voor het verwijderen en toevoegen van opties zijn er 2 manieren: de JS-client manier of de DOM-manier (allebei ter leering ende vermaeck geillustreerd):

JavaScript:

function handleHttpResponse() 
{ 
    if (http.readyState == 4) 
    {
        if (http.status == 200)
        {
            var result = http.responseXML.getElementsByTagName('optie');
            var aantal = result.length;

            var a = document.getElementById('lokaal'); //de select

            // leegmaken

            // JS-methode
            a.options.length = 0;
            // DOM-methode
            while (a.hasChildNodes()) a.removeChild(a.firstChild);

            for (var i = 0, opt; i < aantal; i++)
            {
                // JS-methode
                a.options[i] = new Option(result[i].childNodes[1].firstChild.nodeValue, result[i].childNodes[0].firstChild.nodeValue);

                // DOM-methode
                opt = document.createElement('option');
                opt.appendChild(document.createTextNode(result[i].childNodes[1].firstChild.nodeValue));
                opt.value = result[i].childNodes[0].firstChild.nodeValue;
                a.appendChild(opt);
            }
        }
    } 
}

[XWB]

Dat doet het ja, alleen laat hij de value ipv te tekst in de select box zien.
Volgens mij moet

code:

opt.appendChild(document.createTextNode(result[i].childNodes[0].firstChild.nodeValue));
dit worden:
opt.appendChild(document.createTextNode(result[i].childNodes[1].firstChild.nodeValue));

Maar dan werkt het compleet niet meer

[crisp]

Hacku schreef op zondag 15 januari 2006 @ 00:53:
Dat doet het ja, alleen laat hij de value ipv te tekst in de select box zien.
Volgens mij moet

code:

opt.appendChild(document.createTextNode(result[i].childNodes[0].firstChild.nodeValue));
dit worden:
opt.appendChild(document.createTextNode(result[i].childNodes[1].firstChild.nodeValue));

Maar dan werkt het compleet niet meer

ja sorry, niet getest

Met die aanpassing zou het toch moeten werken, en anders zal je gewoon eens wat moeten debuggen...

[XWB]

childNodes[1] bevat zo te zien niks.

Het zal wel aan de XML output liggen, maar ik zou niet direct weten wat.
childNodes[1] zou <tekst> moeten zijn.

code:

<lijst>
 <optie>
    <waarde>15</waarde>
    <tekst>001</tekst>
 </optie>
 <optie>
    <waarde>6</waarde>
    <tekst>004</tekst>
 </optie>
</lijst>

[XWB]

childNodes[2] laat de tekstwaarde wel zien Waar zit 1 dan?

[crisp]

Hacku schreef op zondag 15 januari 2006 @ 01:13:
childNodes[2] laat de tekstwaarde wel zien Waar zit 1 dan?

whitespace misschien?

[XWB]

Juist. Ik print nl een \n af, had ik niet meer aan gedacht

Zowel de JS als de DOM manier werken. Is er een voorkeur voor één van deze? Anders ga ik voor de DOM manier.

[crisp]

Hacku schreef op zondag 15 januari 2006 @ 01:16:
Juist. Ik print nl een \n af, had ik niet meer aan gedacht

Zowel de JS als de DOM manier werken. Is er een voorkeur voor één van deze? Anders ga ik voor de DOM manier.

De JS-manier is iets meer compatible met oudere browsers (maar die ondersteunen XmlHTTP ws niet eens), voor de rest is er weinig verschil. Mogelijk dat de JS-manier iets sneller is, maar dat zal je ws toch niet merken...

[XWB]

Dan blijf ik wel bij de DOM manier.

Thx crisp, nou kan ik eindelijk wat nachtrust hebben

[djluc]

Voordeel van de DOM methode is dat je altijd dezelfde code kunt gebruiken, ook als het geen option is maar een andere tag. Wat betreft die whitespace in FF, hier staan wat handige functies: http://developer.mozilla.org/en/docs/Whitespace_in_the_DOM