Select-Liste durch <input> erweitern
André Wilke
Ich habe in einem HTML-Formular ein Dropdownmenü (<select>), mit dem ein
Besucher eine Frage in diesem Stil beantworten können soll:
Was ist dein Libelingsgericht?
- Pizza
- Schwarzsauer
- Tomatensuppe
- Etwas anderes
Wenn man in dieser Liste jetzt "Etwas anderes" wählt (und nur dann),
soll ein <input />-Feld unter der Liste erscheinen, in das man dann
seine eigene Antwort eintragen kann, um im Anschluss die Formular-Daten
abzuschicken.
Hat jemand ein kleines Script auf Lager (oder die nötigen Tipps für
einen JS-Neuling), mit dem sich so etwas umsetzen lässt?
Google konnte mir leider nicht helfen, weil mir keine präzisen
Suchbegriffe hierfür einfallen wollen.
Ich bedanke mich vorab für jede Hilfe!
- André
Andreas Eibach
"André Wilke" <andre...@arcor.de> wrote in message
news:47360671$0$13113$9b4e...@newsspool2.arcor-online.net...
Keine Scheu - jeder fängt mal klein an.
Heutzutage [tm] möchte man für sowas nicht mehr die Seite neu laden und
geht folgendermaßen vor:
(Variante 1) (!! hoch-proprietär!! und nicht empfohlen, obwohl Firefox
es duldet (hätte er m. E. nicht müssen))
- Leeres DIV in deine HTML-Seite einfügen:
<DIV id="meindiv"></DIV>
- Jetzt fragst du ab, ob "Etwas anderes" selektiert wurde, und wenn ja:
document.getElementById("meindiv").innerHTML = "<input .... usw.>";
-------------
(Variante 2)
<DIV id="meindiv"><input type="....></DIV>
- _Bevor_ (!) du diese Auswahlliste anzeigst, schaltest du das DIV ab:
document.getElementById("meindiv").style.display = "none";
Das kann auch schon im BODY mit onLoad=abschalten() oder so geschehen.
- Falls "Etwas anderes" ausgewählt wurde:
document.getElementById("meindiv").style.display = "block"; // ODER
"inline"; sollte in deinem Fall nicht von Belang sein
-----------
(Variante 3) schreibe ich hier nicht aus, die ist etwas mehr Tipparbeit,
weil man mit var oInput = document.createElement("INPUT") das Element
dynamisch erzeugt, und alle benötigten Attribute mit Eigenschaften
('.'-Operator) setzen muss (z. B. oInput.type = "submit"; ). Sobald das
Objekt "fertig" ist, wird es dann mit
document.getElementById("meindiv").appendChild (oInput) ins DIV
eingekettet.
-Andreas
Thomas 'PointedEars' Lahn
> "André Wilke" <andre...@arcor.de> wrote in message
> news:47360671$0$13113$9b4e...@newsspool2.arcor-online.net...
Bitte keine Einleitungsromane! ---> http://oe-faq.de/
>> [...]
>> Ich habe in einem HTML-Formular ein Dropdownmenü (<select>), mit dem
>> ein Besucher eine Frage in diesem Stil beantworten können soll:
>>
>> Was ist dein Libelingsgericht?
>> - Pizza
>> - Schwarzsauer
>> - Tomatensuppe
>> - Etwas anderes
>>
>> Wenn man in dieser Liste jetzt "Etwas anderes" wählt (und nur dann),
Für eine solche Auswahl sind Radiobuttons besser geeignet.
>> soll ein <input />-Feld unter der Liste erscheinen, in das man dann
^
Bitte lern den Unterschied zwischen HTML und XHTML. Tipp: Du willst hier
bestimmt kein XHTML benutzen, vertrau mir.
>> seine eigene Antwort eintragen kann, um im Anschluss die
>> Formular-Daten abzuschicken.
>> [...]
>
> [...]
> (Variante 2)
> <DIV id="meindiv"><input type="....></DIV>
>
> - _Bevor_ (!) du diese Auswahlliste anzeigst, schaltest du das DIV ab:
> document.getElementById("meindiv").style.display = "none";
> Das kann auch schon im BODY mit onLoad=abschalten() oder so geschehen.
Es sollte *nur* dort geschehen. Ein div-Element ist jedoch unnötig. Konkret:
...
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function abschalten()
{
document.forms[0].elements["other_text"].style.display = "none";
}
</script>
</head>
<body onload="abschalten()">
<form ...>
...
<label>nämlich: <input name="other_text" ...></label>
...
</form>
</body>
> - Falls "Etwas anderes" ausgewählt wurde:
> document.getElementById("meindiv").style.display = "block"; // ODER
> "inline"; sollte in deinem Fall nicht von Belang sein
Diese Variante ist als einzige empfehlenswert, da dann auch Benutzer ohne
Script-Support etwas von dem Formular haben (man Barrierefreiheit).
Meiner Erfahrung nach sind Benutzer jedoch regelmässig verwirrt, wenn
Inhalte plötzlich aus- oder eingeblendet werden; das input-Element sollte
daher nicht ausgeblendet, sondern lediglich deaktiviert werden; in diesem
Zustand wird es auch beim Absenden des Formulars nicht übertragen. Daher:
function abschalten()
{
document.forms[0].elements["other_text"].disabled = true;
}
PointedEars
--
Andererseits wäre auf einer Seite unter vu-Domain mit Zappelgifs,
Mustertapete, MS Sans Comic und Frames ein fehlender Counter ein
glatter Stilbruch.
(Olaf P÷hlmann in dciwam <asl6a6$rm0$04$1...@news.t-online.com>)
André Wilke
> Andreas Eibach wrote:
>>>[...]
>>>Ich habe in einem HTML-Formular ein Dropdownmenü (<select>), mit dem
>>>ein Besucher eine Frage in diesem Stil beantworten können soll:
>>>
>>>Was ist dein Libelingsgericht?
>>> - Pizza
>>> - Schwarzsauer
>>> - Tomatensuppe
>>> - Etwas anderes
>>>
>>>Wenn man in dieser Liste jetzt "Etwas anderes" wählt (und nur dann),
>
> Für eine solche Auswahl sind Radiobuttons besser geeignet.
Die Liste wird durchaus ein ganzes Stücl länger sein, ich wollte nur ein
konkretes, eingägiges Beispiel zeigen.
>>>soll ein <input />-Feld unter der Liste erscheinen, in das man dann
>
> ^
> Bitte lern den Unterschied zwischen HTML und XHTML.
Längst geschehen. Ich hätte oben bereits XHTML schreiben sollen, hab's
aber vergessen.
> Tipp: Du willst hier bestimmt kein XHTML benutzen, vertrau mir.
Warum sollte ich kein XHTML benutzen?
> <snip: Code und Hinweise>
Vielen Dank Andreas, du hast mir sehr weitergeholfen!
Auch dir vielen Dank, Thomas, für deine Hinweise.
42,
André
Gregor Kofler
> Warum sollte ich kein XHTML benutzen?
U.a.:
Weil es der beste und meistbenutzte Browser auf diesem Erdenrund nicht
unterstützt.
Gregor
--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum
Thomas 'PointedEars' Lahn
> André Wilke meinte:
>> Warum sollte ich kein XHTML benutzen?
>
> U.a.:
>
> Weil es der beste und meistbenutzte Browser auf diesem Erdenrund nicht
> unterstützt.
Der meistbenutzte -- OK. Aber u.a. aus obigem Grund wohl kaum der beste.
Oder hast Du die Sarkasmus-Tags vergessen?
PointedEars
--
Lass den Käse mit MS-Fromage besser sein, lerne HTML (kennen) und designe
mit einem gescheitem Editor (z.B Notepad (c;). (Michael 'Netzmeister Micha'
Specht in http://selfhtml.de/forum/zeigebeitrag_6_78563_78273.php3
Gregor Kofler
> Gregor Kofler wrote:
>> André Wilke meinte:
>>> Warum sollte ich kein XHTML benutzen?
>> U.a.:
>>
>> Weil es der beste und meistbenutzte Browser auf diesem Erdenrund nicht
>> unterstützt.
>
> Der meistbenutzte -- OK. Aber u.a. aus obigem Grund wohl kaum der beste.
> Oder hast Du die Sarkasmus-Tags vergessen?
Offensichtlich... (Und nicht nur aus _diesem_ Grund ist er wohl kaum der
beste.)
Andreas Eibach
"Thomas 'PointedEars' Lahn" <Point...@web.de> wrote:
> Für eine solche Auswahl sind Radiobuttons besser geeignet.
Jo.
>> (Variante 2)
>> <DIV id="meindiv"><input type="....></DIV>
>>
>> - _Bevor_ (!) du diese Auswahlliste anzeigst, schaltest du das DIV
>> ab:
>> document.getElementById("meindiv").style.display = "none";
>> Das kann auch schon im BODY mit onLoad=abschalten() oder so
>> geschehen.
>
> Es sollte *nur* dort geschehen. Ein div-Element ist jedoch unnötig.
> Konkret:
>
> ...
> <meta http-equiv="Content-Script-Type" content="text/javascript">
> <script type="text/javascript">
> function abschalten()
> {
> document.forms[0].elements["other_text"].style.display =
> "none";
> }
> </script>
> </head>
Prinzipiell OK; nur bevorzuge ich <div> aus einem Grund: Unabhängigkeit
vom Elementindex!
Angenommen da kommt in der Zukunft noch ein <form>-Block obendrüber;
dann müsste ich händisch den 0-index in einen 1-index ändern.
Durch div samt id referenziere ich alles unique, und weiß genau was ich
anfasse.
-Andreas
Thomas 'PointedEars' Lahn
Nein, denn das Formular kann einen Namen haben, den Du ebenfalls als
Eigenschaftsnamen verwenden kannst. Es handelt sich heutzutage um ein
Objekt, welches das HTMLCollection-Interface von W3C DOM Level 2 HTML
implementiert. (Das war jedoch bei DOM Level 0 auch, also schon immer, so.)
PointedEars
--
Du fragst Leute, die normalerweise gern Information weitergeben, wie Du
Information verheimlichen kannst? Ist das nicht ein bisschen ... nunja ...
seltsam? (Ulrich 'Droeppez' Kritzner zu einem Quelltextsperrer in
http://selfhtml.de/forum/zeigebeitrag.php3?fid=2&id=39654&thread=39241)
Gregor Kofler
> Prinzipiell OK; nur bevorzuge ich <div> aus einem Grund: Unabhängigkeit
> vom Elementindex!
> Angenommen da kommt in der Zukunft noch ein <form>-Block obendrüber;
Angenommen du willst keine DIVs mit IDs haben...
> dann müsste ich händisch den 0-index in einen 1-index ändern.
Forms kann man ebenso über Namen ansprechen. Forms kann man genauso eine
ID geben.
> Durch div samt id referenziere ich alles unique, und weiß genau was ich
> anfasse.
Naja...
Andreas Eibach
"Thomas 'PointedEars' Lahn" <Point...@web.de> wrote:
> Nein, denn das Formular kann einen Namen haben, den Du ebenfalls als
> Eigenschaftsnamen verwenden kannst. Es handelt sich heutzutage um ein
> Objekt, welches das HTMLCollection-Interface von W3C DOM Level 2 HTML
> implementiert. (Das war jedoch bei DOM Level 0 auch, also schon
> immer, so.)
Dann sage mir doch bitte auch, wie man das anspricht, damit ich nicht
wieder diese unsägliche MS-Krücke document.all verwenden muss. Dass ich
es _dort_ direkt ansprechen kann, weiß ich. Nur für mich existiert
document.all faktisch nicht :)
-Andreas
Thomas 'PointedEars' Lahn
> "Thomas 'PointedEars' Lahn" <Point...@web.de> wrote:
>> Nein, denn das Formular kann einen Namen haben, den Du ebenfalls als
>> Eigenschaftsnamen verwenden kannst. Es handelt sich heutzutage um ein
>> Objekt, welches das HTMLCollection-Interface von W3C DOM Level 2 HTML
>> implementiert. (Das war jedoch bei DOM Level 0 auch, also schon
>> immer, so.)
>
> Dann sage mir doch bitte auch, wie man das anspricht, damit ich nicht
Gern.
<head>
...
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function disableInput()
{
document.forms["foo"].elements["bar"].disabled = true;
}
</script>
...
</head>
<body onload="disableInput();">
...
<form action="..." ... name="foo">
...
<input ... name="bar">
...
</form>
...
</body>
Bei UAs, die mindestens W3C DOM Level 1 HTML implementieren, funktioniert
das mit Namen und IDs, sonst nur mit Namen.
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26809268
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506
http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html
HTH
PointedEars
--
Bedenke, daß Mozilla bereits 4 Jahre alt ist. Du kannst Dir also ausrechnen,
wie veraltet NN4 ist. Trotzdem ist er der erfolgreichste Browser aller
Zeiten. Kein Fossil ist je so alt geworden wie dieser Browser einen aussehen
läßt. ;-) -- Georg Maaß in dcljs <aouobi$q4qm6$1...@ID-3551.news.dfncis.de>
Andreas Eibach
"Thomas 'PointedEars' Lahn" <Point...@web.de> wrote:
> function disableInput()
> {
> document.forms["foo"].elements["bar"].disabled = true;
> }
> </script>
Aaah, jetzt schnackelts. Danke.
"Assoziatives Array" und "Key" hätten mich bereits auf die richtige Spur
gebracht. :)
-Andreas
Thomas 'PointedEars' Lahn
Das wäre tragisch, handelt es sich doch hierbei weder um ein Array, noch
unterstützten ECMAScript-Implementationen die Datenstruktur "assoziatives
Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
PointedEars
--
[FrontPage] Dann wechsle schnellstens zu Notpatsch.echse, dann mußt Du
alle Buchstaben selber eingeben und Dir auch bei jedem überlegen, ob der
dahingehört bzw. weggelassen werden kann.
(Georg Maaß in dcljs <b57nm8$25hka6$1...@ID-3551.news.dfncis.de>)
Ferry Bolhar
>> Aaah, jetzt schnackelts. Danke.
>> "Assoziatives Array" und "Key" hätten mich bereits auf die richtige Spur
>> gebracht. :)
>
> Das wäre tragisch, handelt es sich doch hierbei weder um ein Array, noch
> unterstützten ECMAScript-Implementationen die Datenstruktur "assoziatives
> Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
Ich halte das nicht für so tragisch, denn obwohl du recht hast,
kommt die Wirkungsweise des Ausdrucks der von assoziativen
Arrays recht nahe. Es gibt sogar JS-Bücher (und das sind IMHO
nicht die schlechtesten), in denen hier von "Keys" die Rede ist,
auch wenn es sich eigentlich um Objektattribute handelt. Wichtig
ist doch letztlich, dass man versteht, worum es geht, und jeder,
der zB. schon mal mit Perl oder PHP gearbeitet hat, wird den
Einstieg in diese Materie leichter finden, wenn er diese Begriffe
hört bzw. liest.
LG, Ferry
--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
Gregor Kofler
> Thomas "PointerEars" Lahn:
>
>>> Aaah, jetzt schnackelts. Danke.
>>> "Assoziatives Array" und "Key" hätten mich bereits auf die richtige Spur
>>> gebracht. :)
>> Das wäre tragisch, handelt es sich doch hierbei weder um ein Array, noch
>> unterstützten ECMAScript-Implementationen die Datenstruktur "assoziatives
>> Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
>
> Ich halte das nicht für so tragisch, denn obwohl du recht hast,
> kommt die Wirkungsweise des Ausdrucks der von assoziativen
> Arrays recht nahe.
"Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
"Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
sehr schnell auf Probleme (der "Array" hat keine Länge, ein "for ... in"
kann mir noch alles Mögliche liefern, etc.)
> Es gibt sogar JS-Bücher (und das sind IMHO
> nicht die schlechtesten), in denen hier von "Keys" die Rede ist,
Tolle Bücher.
> auch wenn es sich eigentlich um Objektattribute handelt. Wichtig
> ist doch letztlich, dass man versteht, worum es geht, und jeder,
> der zB. schon mal mit Perl oder PHP gearbeitet hat, wird den
> Einstieg in diese Materie leichter finden, wenn er diese Begriffe
> hört bzw. liest.
Nein. Jeder der PHP und dessen assoziative Arrays kennt, wird seine
Probleme mit den "assoziativen" Arrays von JS haben - weil vieles, was
er von PHP kennt, in der JS Variante nicht oder jedenfalls deutlich
anders funktioniert.
Gruß, Gregor
Andreas Eibach
"Ferry Bolhar" <b...@adv.magwien.gv.at> wrote:
> Thomas "PointerEars" Lahn:
>
>>> Aaah, jetzt schnackelts. Danke.
>>> "Assoziatives Array" und "Key" hätten mich bereits auf die richtige
>>> Spur
>>> gebracht. :)
>>
>> Das wäre tragisch, handelt es sich doch hierbei weder um ein Array,
>> noch
>> unterstützten ECMAScript-Implementationen die Datenstruktur
>> "assoziatives
>> Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
>
> Ich halte das nicht für so tragisch, denn obwohl du recht hast,
> kommt die Wirkungsweise des Ausdrucks der von assoziativen
> Arrays recht nahe. Es gibt sogar JS-Bücher (und das sind IMHO
> nicht die schlechtesten), in denen hier von "Keys" die Rede ist,
> auch wenn es sich eigentlich um Objektattribute handelt.
Stimmt, mein Flanagan - und genau da hab ichs her.
:P
-Andreas
Thomas 'PointedEars' Lahn
Flanagan hat ja auch JavaScript nicht wirklich kapiert, geschweige denn
ECMAScript. So erklärt er in seinem Buch `[' und `]' ernsthaft als
Array-Operatoren, wo doch jeder mit einem Minimalclue (spätestens jedoch
nach Lesen dieses Threads) weiss, dass es sich lediglich um
Eigenschaftszugriffsyntax mit eckigen Klammern handelt, die *auch*, aber
keineswegs ausschliesslich, bei Array-Objekten Anwendung finden kann.
Jenes Buch (insbesondere ältere Ausgaben) gehört gleichzeitig zu den
meistempfohlenen und zu den fehlerhaftesten, wovon man sich u.a. bei der
Recherche in comp.lang.javascript überzeugen kann[1]. Mangels besserer
Alternativen (kein kompetenter Regular wird ein Buch schreiben oder die
bestehenden Bücher vollständig korrekturlesen, es sei denn vielleicht er
wird dafür bezahlt), wird die 4. Ausgabe als "das am wenigsten schlechte
Buch (bei hoher Toleranz)" bezeichnet, und es wird dringend geraten, die
Errata zu lesen. Das Problem mit den Errata ist jedoch, dass der Autor
dort nur Korrekturen einfliessen lässt, die er akzeptiert; mangels
ausreichenden Verständnisses für die Sprache auf Autorenseite bleiben
somit zahlreiche berechtigte Korrekturen von Wissenden unberücksichtigt.
PointedEars
___________
[1] <fbfm4v$c10$1$8300...@news.demon.co.uk>
Thomas 'PointedEars' Lahn
> Ferry Bolhar meinte:
>> Thomas "PointerEars" Lahn:
>>>> Aaah, jetzt schnackelts. Danke.
>>>> "Assoziatives Array" und "Key" hätten mich bereits auf die richtige Spur
>>>> gebracht. :)
>>> Das wäre tragisch, handelt es sich doch hierbei weder um ein Array, noch
>>> unterstützten ECMAScript-Implementationen die Datenstruktur "assoziatives
>>> Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
>> Ich halte das nicht für so tragisch, denn obwohl du recht hast,
>> kommt die Wirkungsweise des Ausdrucks der von assoziativen
>> Arrays recht nahe.
>
> "Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
> "Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
> sehr schnell auf Probleme
Yep.
> (der "Array"
(MUSEN: *das* Array.)
> hat keine Länge,
Bei Objekten, die das HTMLCollection-Interface implementieren, trifft
jedenfalls das nicht zu: es gibt eine length-Eigenschaft, welche die Anzahl
der Elemente in der Collection liefert.
> ein "for ... in" kann mir noch alles Mögliche liefern, etc.)
Full ACK. Zum "etc. wäre z.B. noch zu erwähnen, dass das Löschen eines
Elements der Collection "mittendrin" automatisch die Veränderung aller
numerischen Indizes der anderen Elemente zur Folge hat, da eine
HTMLCollection "live" ist. Auch dies ist bei assoziativen Arrays nicht
der Fall.
PointedEars
--
ich benutze den Befehl BOQuery, um Daten aus meiner Datenbank zu lesen.
Dieser funktioniert im IE 6 auch meistens. Aber auf manchen Rechnern bei
uns in der Firma funktioniert er nicht. [...] Was muß ich installieren?
(Reiner Wahnsiedler in dcljs <ardkdn$d0q$07$1...@news.t-online.com>)
Ferry Bolhar
> "Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
> "Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
> sehr schnell auf Probleme (der "Array" hat keine Länge
Ach so? Das "length" Attribut ist nichts?
> ein "for ... in"
> kann mir noch alles Mögliche liefern, etc.)
Was verstehst du unter "alles Mögliche"? Es liefert alle Attribute eines
Objektes, soferne diese nicht als "nicht enumerierbar" gekennzeichnet
sind. Oder habe ich da etwas ve gessen?
> > Es gibt sogar JS-Bücher (und das sind IMHO
> > nicht die schlechtesten), in denen hier von "Keys" die Rede ist,
>
> Tolle Bücher.
Wenn's das Verständnis fördert?
> Nein. Jeder der PHP und dessen assoziative Arrays kennt, wird seine
> Probleme mit den "assoziativen" Arrays von JS haben - weil vieles, was
> er von PHP kennt, in der JS Variante nicht oder jedenfalls deutlich
> anders funktioniert.
Noch einmal: es geht nicht um die konkrete Implementierung (die ist
sowieso immer anders), sondern um das grundsätzliche Verständnis.
Es ist mir schon klar, dass ECMA-Script keine assoziativen Arrays
im klassischen Sinne kennt. Aber die grundsätzliche Idee läßt sich
daraus ableiten, insoferne halte ich Vergleiche (wo natürlich auch
auf die Unterschiede hingewiesen wird) für gerechtfertigt und für
das Verständnis über die Wirkungsweise z.B. dieses Ausdrucks
document.forms["foo"].elements["bar"]
sogar für sehr hilfreich.
Ferry Bolhar
> Full ACK. Zum "etc. wäre z.B. noch zu erwähnen, dass das Löschen eines
> Elements der Collection "mittendrin" automatisch die Veränderung aller
> numerischen Indizes der anderen Elemente zur Folge hat, da eine
> HTMLCollection "live" ist. Auch dies ist bei assoziativen Arrays nicht
> der Fall.
Das trifft aber nur auf HTML-Collections zu. Zumindest wäre mir neu,
dass in einer "Collection" (um jetzt mal bei diesem Ausdruck zu bleiben)
wie:
var myObject = new Object();
myObject["testa"] = "TestA";
myObject["testb"] = "TestB";
sich irgendein Index ändert, wenn das Element "testa" gelöscht wird.
Das von dir beschriebene Verhalten hat daher mit der ECMA-
Implementierung von Objekten/Collections und Attributen/Elementen
ansich nichts zu tun, sondern ist etwas HTML (DOM)-Spezifisches.
LG, Ferry
--
"J. Strübig"
> Gregor Kofler:
>
>> "Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
>> "Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
>> sehr schnell auf Probleme (der "Array" hat keine Länge
>
> Ach so? Das "length" Attribut ist nichts?
Genauer, length ist undefiniert.
>> ein "for ... in"
>> kann mir noch alles Mögliche liefern, etc.)
>
> Was verstehst du unter "alles Mögliche"? Es liefert alle Attribute eines
> Objektes, soferne diese nicht als "nicht enumerierbar" gekennzeichnet
> sind. Oder habe ich da etwas ve gessen?
Ja, und Attribute kann alles sein. Während du in einem HASH nur die
Schlüssel siehst. Das wird ein Problem wenn z.b. eines dieser beliebten
JS Frameworks verwendet wird und das den Objetc.prototype erweitert, aus
welchen Gründen auch immer.
Ich hab z.b. so einen Code:
Object.prototype.extendObj = function(source)
{
for (var property in source) this[property] = source[property];
}
var o = {};
o['Eigenschaft'] = 'wert'
for(var a in o) alert(a);
> Es ist mir schon klar, dass ECMA-Script keine assoziativen Arrays
> im klassischen Sinne kennt. Aber die grundsätzliche Idee läßt sich
> daraus ableiten, insoferne halte ich Vergleiche (wo natürlich auch
> auf die Unterschiede hingewiesen wird) für gerechtfertigt und für
> das Verständnis über die Wirkungsweise z.B. dieses Ausdrucks
>
> document.forms["foo"].elements["bar"]
>
> sogar für sehr hilfreich.
Vielleicht muss man hier aus der VB Ecke kommen, um das zu verstehen
ohne von assoziativen Arrays zu sprechen.
Der Ausdruck ist:
document.forms.foo.elements.bar
und das hat für mich nichts mit einem AA oder HASH zu tun, ich sehe
einfach verschachtelte Objekte und finde den Vergleich mit einem AA
nicht hilfreich. Und man merkt es daran, seit z.b. in selfhtml nicht
mehr von einem AA die Rede ist tauchen hier weniger Fragen dazu auf,
weil die Leute nicht mehr die Erwartung haben dass es eines ist. Davor
kam regelmäßig die Frage warum length bei einem AA undefiniert ist.
Insofern ist mein subjektiver Eindruck, auch wegen der Erfahrung in
Foren und hier, dass es eben nicht das Verständniss fördert.
Struppi.
Thomas 'PointedEars' Lahn
> Ferry Bolhar meinte:
>> Thomas "PointerEars" Lahn:
>>>> Aaah, jetzt schnackelts. Danke.
>>>> "Assoziatives Array" und "Key" hätten mich bereits auf die richtige Spur
>>>> gebracht. :)
>>> Das wäre tragisch, handelt es sich doch hierbei weder um ein Array, noch
>>> unterstützten ECMAScript-Implementationen die Datenstruktur "assoziatives
>>> Array" nativ. "foo" und "bar" sind folglich auch keine "Keys".
>> Ich halte das nicht für so tragisch, denn obwohl du recht hast,
>> kommt die Wirkungsweise des Ausdrucks der von assoziativen
>> Arrays recht nahe.
>
> "Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
> "Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
> sehr schnell auf Probleme
Yep.
> (der "Array"
(MUSEN: *das* Array.)
> hat keine Länge,
Bei Objekten, die das HTMLCollection-Interface implementieren, trifft
jedenfalls das nicht zu: es gibt eine length-Eigenschaft, welche die Anzahl
der Elemente in der Collection liefert.
> ein "for ... in" kann mir noch alles Mögliche liefern, etc.)
Full ACK. Zum "etc." wäre z.B. noch zu erwähnen, dass das Löschen eines
Elements der Collection "mittendrin" automatisch die Veränderung aller
numerischen Indizes der anderen Elemente zur Folge hat, da eine
HTMLCollection "live" ist. Auch dies ist bei assoziativen Arrays nicht
der Fall.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Thomas 'PointedEars' Lahn
> Ferry Bolhar schrieb:
>> Gregor Kofler:
>>> "Recht nahe". Es sind aber keine assoziativen Arrays, und wenn ich diese
>>> "Arrays" wie in anderen Sprachen üblich verarbeiten will, dann stoße ich
>>> sehr schnell auf Probleme (der "Array" hat keine Länge
>> Ach so? Das "length" Attribut ist nichts?
>
> Genauer, length ist undefiniert.
Jedoch nicht bei Objekten, die HTMLCollection implementieren.
> ich sehe einfach verschachtelte Objekte [...]
Naja, "verschachtelte Objekte" ist dann auch wieder übersimplifiziert.
> Insofern ist mein subjektiver Eindruck, auch wegen der Erfahrung in
> Foren und hier, dass [die Bezeichnung "assoziatives Array" für Objekte]
> eben nicht das Verständniss fördert.
Full ACK :)
PointedEars