[HTML/JS] SELECT wil niet met innerHTML

[ronaldmathies]

Ik heb in Javascript het volgende staan:

document.getElementById('contactKey').innerHTML = "<option value='1'>test</option>";

waarbij de contactKey een id is van een HTML select lijst:

<select id="contactKey" size="1" style="width : 225px">
</select>

als het bovenstaande echter uit wordt gevoerd dan zie ik in de DOM inspector van Firefox het volgende als resultaat:

<select id="contactKey" size="1" style="width : 225px">
test
</select>

Waarom raken de HTML tags eromheen verloren?
En wat kan ik hier tegen doen?

[Woudloper]

Wat wil je eigenlijk doen? Wil je met behupl van DOM een option toevoegen aan een form SELECT? Zo ja, dan moet je het niet op deze manier doen...

[ronaldmathies]

Nee de informatie die ik via de innerHTML wil toevoegen komt uit een JSP Serlvet

Dit is de gehele code:

Wat er gebeurt is is als de onchange van de <select> afgaat dan wordt de contractorOnChangeSend aangeroepen met een bepaalde sleutel. vervolgens wordt via de request informatie opgehaald. Als alles goed gaat dan wordt door de browser contractorOnChangeProcess aangeroepen. waarna ik het resultaat van de request.responseText in de innerHTML van de contactKey <select> lijst wil stoppen.

code:

    function contractorOnChangeSend(contractorKey) {
        if (contractorKey > 0) {
            try {
        request = new ActiveXObject("Msxml2.XMLHTTP");
        } catch(exception) {
        try {
            request = new ActiveXObject("Microsoft.XMLHTTP");
        } catch(exception) {
                    request = null;
        }
        }

        if (!request && typeof XMLHttpRequest!="undefined") {
                request = new XMLHttpRequest();
        }
    
        var url="<%=request.getContextPath()%>/main/application/contract/GetContacts?contractorKey=" + contractorKey;
        
        if (request != null) {
                request.onreadystatechange = contractorOnChangeProcess;
                request.open("GET", url, true);
                request.send(null);
        }
        }
    }

    function contractorOnChangeProcess() {
    if (request.readyState == 4) {
      // Only if HTTP status is 200 (OK)
        if (request.status == 200) {
        if(request.responseText != "") {
          document.getElementById('contactKey').innerHTML = request.responseText;
          alert(request.responseText);
        }
        }
    }
    }

De alert geeft aan dat de inhoud van de request.responseText het volgende is:

<option value="1">Geen</option>
<option value="2">Een</option>
<option value="3">Twee</option>

Dus de inhoud is goed, alleen raakt de HTML vervloren (del <option ..> </option> tags).

[ Voor 19% gewijzigd door ronaldmathies op 17-02-2005 12:54 ]

[Woudloper]

Waarom met 'innerHTML', ja kan toch ook iets doen zoals:

JavaScript:

var sellist = document.getElementById('contactKey');
var i = sellist.options.count;

sellist(i + 1) = new Option('Test');
sellist(i + 1).value = 'TestValue';

edit:
Code uit mijn hoofd en niet gecontroleerd, dus weet niet of het volledig correct is...

[ Voor 26% gewijzigd door Woudloper op 17-02-2005 12:56 ]

[ronaldmathies]

Woudloper schreef op donderdag 17 februari 2005 @ 12:55:
Waarom met 'innerHTML', ja kan toch ook iets doen zoals:

JavaScript:

var sellist = document.getElementById('contactKey');
var i = sellist.options.count;

sellist(i + 1) = new Option('Test');
sellist(i + 1).value = 'TestValue';

edit:
Code uit mijn hoofd en niet gecontroleerd, dus weet niet of het volledig correct is...

Dit omdat het resultaat wat ik uit de request terugkrijg al compleet geformateerd is mbv ECS (apache library waarmee je via Java (geen javascript) HTML kan maken waarbij dit automatisch kloppend gemaakt word). Dus dan moet ik meer Javascript maken om het op te lossen en ik wil zo min mogelijk javascript.

Maar waar het me ook om gaat is, is waarom lukt innerHTML bijvoorbeeld wel met een <div> maar niet met een <select>.

[RM-rf]

'innerHTML' is een hele lelijke manier om de inhoud van Nodes aan te passen, omdat het eigenlijk ascii-text toevoegt, die helaas ook weer markup kan bevatten ...
bij de introductie als proprietair element door MicroSoft was dit de grootste 'klacht' van HTML-engine-developpers en XML-mensen, omdat het ontegenzeggelijk leek te leiden tot bugs en verkeerd gebruik van DOM ...

omdat het element uiteindelijk erg populair onder webdesigners, eigenlijk ook omdat het de enige manier was om content binnen element eenvoudig op te vragen en te wijzigen in de versie-4-browsers ...

wil je bugs als deze voorkomen, ontkom je niet aan het parsen van zulke content en werkelijk invoegen via nette obvject-methodes (overigens, Woudloper post volgens mij wel een werkende, maar toch een ietwat vreemde vermengeling van de DOM-methode en de oudere 'document.forms-methode' die al bestaat sinds de introductie van javascript) ...

Er zijn eventueel wel wat andere 'hacks' die kunnen werken, bv door niet zozeer de inhoud van de select te wijzigen, wat kennelijk niet juist gerenderd wordt, maar in plaats daarvan het ParentElement van dit element te pikken en hierin via een regExp de inhoud van de innerHTML te vervangen, maar oei, wat is dat lelijk (en dus vragen om nieuwe bugs)

ronaldmathies schreef op donderdag 17 februari 2005 @ 12:59:

Dus dan moet ik meer Javascript maken om het op te lossen en ik wil zo min mogelijk javascript.

Dat is een non-methode ... natuurlijk is het erg goed om duidelijk rekening te houden met non-javascript browsers (toch 5 tot 10%) en een applicatie ook in non-javascript zoveel mogelijk te laten functioneren ..
maar in dit geval gebruik je javascript al voor essentiele handelingen ... dan maakt het niks meer uit of dat twee regels zijn, of zevenenzestig ...

[ Voor 19% gewijzigd door RM-rf op 17-02-2005 13:06 ]

[ronaldmathies]

RM-rf schreef op donderdag 17 februari 2005 @ 13:04:
'innerHTML' is een hele lelijke manier om de inhoud van Nodes aan te passen, omdat het eigenlijk ascii-text toevoegt, die helaas ook weer markup kan bevatten ...
bij de introductie als proprietair element door MicroSoft was dit de grootste 'klacht' van HTML-engine-developpers en XML-mensen, omdat het ontegenzeggelijk leek te leiden tot bugs en verkeerd gebruik van DOM ...

Of het alleen door microsoft geïntroduceert is weet ik niet, het is door IE4 en Netscape 6 geintroduceert. Dat wat jij bedoeld met ASCII is de innerText, deze is inderdaad ASCII georienteerd.

omdat het element uiteindelijk erg populair onder webdesigners, eigenlijk ook omdat het de enige manier was om content binnen element eenvoudig op te vragen en te wijzigen in de versie-4-browsers ...

wil je bugs als deze voorkomen, ontkom je niet aan het parsen van zulke content en werkelijk invoegen via nette obvject-methodes (overigens, Woudloper post volgens mij wel een werkende, maar toch een ietwat vreemde vermengeling van de DOM-methode en de oudere 'document.forms-methode' die al bestaat sinds de introductie van javascript) ...

Er zijn eventueel wel wat andere 'hacks' die kunnen werken, bv door niet zozeer de inhoud van de select te wijzigen, wat kennelijk niet juist gerenderd wordt, maar in plaats daarvan het ParentElement van dit element te pikken en hierin via een regExp de inhoud van de innerHTML te vervangen, maar oei, wat is dat lelijk (en dus vragen om nieuwe bugs)


[...]


Dat is een non-methode ... natuurlijk is het erg goed om duidelijk rekening te houden met non-javascript browsers (toch 5 tot 10%) en een applicatie ook in non-javascript zoveel mogelijk te laten functioneren ..
maar in dit geval gebruik je javascript al voor essentiele handelingen ... dan maakt het niks meer uit of dat twee regels zijn, of zevenenzestig ...

Het is niet zozeer dat ik Javascript wil vermeiden omdat er browsers zijn die het niet ondersteunen maar meer vanwege het feit dat mijn web applicatie door bedrijven gebruikt worden (het is een product) wat de volgende browsers moet ondersteunen , IE, Safari, FireFox, Opera. Sommige browsers interpreteren Javascript op een andere manier dan andere, dit kan op het ene moment werken maar met een nieuwe versie van een browser verpest zijn. Dit wil ik voorkomen door zo min mogelijk javascript te gebruiken.

Maar ik zal eens kijken wat ik met DOM kan bereiken.

[ Voor 3% gewijzigd door ronaldmathies op 17-02-2005 13:19 ]

[ronaldmathies]

De volgende oplossing werkt bij mij:

code:

function contractorOnChangeProcess() {
    var rows;
    var columns;
    var contactKeyField = document.getElementById('contactKey');
    
if (request.readyState == 4) {
  // Only if HTTP status is 200 (OK)
    if (request.status == 200) {
    if(request.responseText != "") {
        alert(request.responseText);
        rows = request.responseText.split(/\s*,\s*/);
        
      contactKeyField.options.length = 0;
        
        for (var index = 0; index < rows.length; index++) {
                    columns = rows[index].split(/\s*;\s*/);
                    alert("\"" + columns[1] + "\"");
                    // Add an option to the html select list.                       
                    contactKeyField.options[index] = new Option(columns[1], columns[0], false, false);
                }
    }
    }
}
}

De informatie in request.responseText is nu als volgt opgebouwd : "key;value,key;value,key;value" en dit werkt ook in Internet Explorer, Safari. De overige browsers moet ik nog testen.

[RM-rf]

ronaldmathies schreef op donderdag 17 februari 2005 @ 13:19:
[...]


Of het alleen door microsoft geïntroduceert is weet ik niet, het is door IE4 en Netscape 6 geintroduceert. Dat wat jij bedoeld met ASCII is de innerText, deze is inderdaad ASCII georienteerd.

Wat ik ermee bedoelde is dat innerHTML evensterk 'platte tekst' is als innerText, gewoon een string-variabele, zelfs als dit stuk meerdere nodes omvat (en dat is dus ook precies het probleem)

Het is niet zozeer dat ik Javascript wil vermeiden omdat er browsers zijn die het niet ondersteunen maar meer vanwege het feit dat mijn web applicatie door bedrijven gebruikt worden (het is een product) wat de volgende browsers moet ondersteunen , IE, Safari, FireFox, Opera. Sommige browsers interpreteren Javascript op een andere manier dan andere, dit kan op het ene moment werken maar met een nieuwe versie van een browser verpest zijn. Dit wil ik voorkomen door zo min mogelijk javascript te gebruiken.

Maar ik zal eens kijken wat ik met DOM kan bereiken.

Javascript (of eigenlijk ecmascript) is binnen elke browser exact gelijk ... sterker nog, zelf flash's actionscript, een intern batch-scriptingtaal binnen photoshop en de taal om interface-handelingen binnen Dreamweaver te automatiseren, en een serverside ASP-taal (serverside Jscript) ... voldoen allemaal aan de ecma-standaard en zijn als 'scripting' an sich uitwisselbaar ...

Wat hooguit kan veranderen zijn de bestaande objecten die aanspreekbaar zijn.. en daar is juist DOM de oplossing, omdat dat evenzeer een standaard is, met gedocumenteerde methoden...
als je DOM gebruikt kun je ervan opaan dat dit juist een standaard is waar vrijwel alle browser-bouwers aan pogen te conformeren..., natuurlijk kunnen er afwijkingen zijn, soms wat 'domme' gedragingen die browsers inbouwen om elkaar de loep af te steken...
maar juist DOM doet een poging hierin vaste richtlijnen neer te zetten en is daarin redelijk geslaagd.

[Woudloper]

Overigens kan je voor het middels DOM javascript toevoegen van select options nog kijken naar de Javascript sectie van de W&G FAQ (welke op dit moment onder hande is), daar staat namelijk ook nog hoe je opties kan toevoegen e.d.