[JS] Hoe this laten verwijzen naar select element?

[Reveller]

Ik heb de volgende code:

HTML:

<script>
function select_goto(ignore) {
  var selected = this.options[this.selectedIndex].value;

  if (selected == ignore) {
    url = 'admin';
  }
  else {
    url = 'admin/content/view/' + selected;
  }

  document.location.href = url;
}
</script>

<select onchange="select_goto('all')">
  <option value="all">alles...
  <option value="images">plaatjes
  <option value="files">bestanden
</select>

Als de gebruiker de optie "alles..." selecteert, wil ik de pagina refreshen naar een andere url dan wanneer de gebruiker een andere optie kiest. Als ik deze code echter uitvoer, krijg ik een foutmelding:

this.options has no properties

Als ik regel 16 aanpas, blijf ik dezelfde foutmelding houden:

HTML:

<select onchange="select_goto(this, 'all')">

Hoe krijg ik deze code nu werkend?

[Cyphax]

Het element niet meegeven als parameter, maar in de functie select_goto() ophalen welk element het event heeft getriggered.
Lees maar eens door: http://www.quirksmode.org/js/events_properties.html

[André]

HTML:

<script>
function select_goto(obj, ignore) {
  var selected = obj.options[obj.selectedIndex].value;

  if (selected == ignore) {
    url = 'admin';
  }
  else {
    url = 'admin/content/view/' + selected;
  }

  document.location.href = url;
}
</script>

<select onchange="select_goto(this, 'all')">
  <option value="all">alles...
  <option value="images">plaatjes
  <option value="files">bestanden
</select>

[crisp]

Cyphax schreef op vrijdag 06 april 2007 @ 19:52:
Het element niet meegeven als parameter, maar in de functie select_goto() ophalen welk element het event heeft getriggered.
Lees maar eens door: http://www.quirksmode.org/js/events_properties.html

oeh, cross-browser hell - zeker met IE's brakke eventmodel en de nog brakkere manier waarop IE met select-elementen omgaat

De unobtrusive manier lijkt me overigens het best:

JavaScript:

selectElement.onchange = handler;

waarbij 'this' binnen je handler naar je select-element verwijst. Voor het meegeven van extra parameters zal je nog wel wat moeten smokkelen met een wrappertje, maar als je een generieke neemt zoals deze dan heb je er ook in andere gevallen nog wat aan

[ Voor 33% gewijzigd door crisp op 06-04-2007 20:24 ]

[Cyphax]

crisp schreef op vrijdag 06 april 2007 @ 20:20:
[...]

oeh, cross-browser hell - zeker met IE's brakke eventmodel en de nog brakkere manier waarop IE met select-elementen omgaat

Oh.
Is het echt zo erg?

Voor zoiets simpels zal het toch wel werken?

(ik heb er weleens mee zitten klooien maar dat was volgens mij met name dat gebubbel wat erbij kwam kijken, voor zoiets simpels als dit gaat dat toch wel? )

[crisp]

Cyphax schreef op vrijdag 06 april 2007 @ 20:56:
[...]

Oh.
Is het echt zo erg?

Voor zoiets simpels zal het toch wel werken?

(ik heb er weleens mee zitten klooien maar dat was volgens mij met name dat gebubbel wat erbij kwam kijken, voor zoiets simpels als dit gaat dat toch wel? )

Dit werkt inderdaad wel:

HTML:

<script type="text/javascript">

function test(event)
{
    var target = event.target || event.srcElement;

    alert(target.nodeName);
}

</script>
<select id="foo" onchange="test(event)">
    <option value="1">1</option>
    <option value="2">2</option>
    <option value="3">3</option>
    <option value="4">4</option>
    <option value="5">5</option>
</select>

maar waarom zou je dan niet meteen de handle naar je SELECT-element meegeven mbv het 'this' keyword?

Mbv een meer unobtrusive methode waarbij je de eventhandler seperaat van je markup toevoegd heb je bij het 'DOM level 0' en W3C eventmodel al automagisch de juiste scope ('this' binnen je handler verwijst dan naar het element zelf), dus dan is het ook maar een rare detour.

De enige reden dat je via het event-object wel het target-element moet zien te achterhalen is wanneer je IE's propriety event-model gebruikt (attachEvent), maar dat model is zo verschrikkelijk broken by design dat je dat eigenlijk nooit zou moeten willen. Daarbij is srcElement per definitie niet gelijk aan het element waarop de handler gedefinieerd is (denk aan geneste elementen waarbij de handler op een 'lager gelegen' niveau is gespecificeerd, bijvoorbeeld een LI-element met een onclick handler en daarin een SPAN ofzo).

Vwb het probleem met het SELECT-element: verander onchange eens in onclick en geef de SELECT een size=5 en selecteer dan eens een optie; IE geeft dan nog steeds de SELECT als srcElement aan, maar echte browsers het aangeklikte OPTION-element

[ Voor 4% gewijzigd door crisp op 06-04-2007 23:26 ]

[Cyphax]

crisp schreef op vrijdag 06 april 2007 @ 23:24:
maar waarom zou je dan niet meteen de handle naar je SELECT-element meegeven mbv het 'this' keyword?

Zat ik even over na te denken maar het komt erop neer dat ik gewoon eigenlijk niet zo gek ben op inline javascript... "onload='func(this)'"
Mixen van Javascript en HTML dus.

[crisp]

Cyphax schreef op zaterdag 07 april 2007 @ 00:05:
[...]

Zat ik even over na te denken maar het komt erop neer dat ik gewoon eigenlijk niet zo gek ben op inline javascript... "onload='func(this)'"
Mixen van Javascript en HTML dus.

Ik ook niet, maar met een unobtrusive manier blijft het bepalen van je object middels het event-object ook een detour (en zelfs een gevaarlijke RE mijn voorbeeld met geneste elementen) omdat je handler sowieso in de scope van je object wordt uitgevoerd - tenzij je op 1 of andere manier toch IE's brakke event-model gebruikt...

Ik weet dat deze versie van addEvent nog veel gebruikt wordt, maar in complexere (nou ja, eigenlijk alle) situaties is dat ten zeerste af te raden omdat attachEvent (IE) en addEventListener (W3) zeker niet uitwisselbaar zijn.

[ Voor 23% gewijzigd door crisp op 07-04-2007 00:34 ]