Link mit festen Index möglich?

[sap01]

Hallo,

ein Link kann eine id oder einen Namen haben. -Soweit kein Problem.

-Aber kann ein Link auch eine feste Indexnummer haben?

[Gunnar Bittersmann]

@@sap01:

nuqneH

-Aber kann ein Link auch eine feste Indexnummer haben?

Entweder @tabindex [[http://www.edition-w3c.de/TR/1999/REC-html401-19991224/interact/forms.html#h-17.11.1@title=HTML401 §17.11.1], http://de.selfhtml.org/html/verweise/tastatur.htm@title=SELFHTML] oder Häh?

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Oops, [HTML401 §17.11.1, http://de.selfhtml.org/html/verweise/tastatur.htm@title=SELFHTML]

Qapla'

[Beat]

ein Link kann eine id oder einen Namen haben. -Soweit kein Problem.

-Aber kann ein Link auch eine feste Indexnummer haben?

Nein. Index ist eine Eigenschaft einer JS-Collection, über welche du iterierst. Besonders bei einer Live-Nodeliste ist nicht garantiert, dass ein Node immer den gleichen Index hat. Bei einer statischen Nodelist geht, sobald man das betroffene DOM manipuliert, die Nodeliste eh verloren.

Du kannst natürlich eine Elementreferenz in einem Array speichern und behältst dann Zugriff über das Array-Element. Aber das hat dann nichts mit der Reihenfolge des Elements im DOM mehr zu tun.

mfg Beat

[sap01]

Schade, dass das feste Zuordnen eines Indexes nicht geht!

In dem Cookie :

reiheC=3;reiheB=15;reiheA=24;

... befinden sich die Link-id(der Link-name) und seine Aufrufzahlen:

Liest man das Cookie aus, so hat man immer ein
Variablen-Paar (eine mit dem Namen und eine mit Zählerwert), z.B.

reiheC  3
was bedeutet, dass der Link mit dem Namen ReiheC dreimal geklickt wurde.

Die Variable "reiheC" ist eine Variable vom Typ "String". -Kann man
den String "reiheC" zu einem Objekt "umtaufen"?

-Wenn das geht, könnte man schreiben:
reiheC.innerHTML=irgendwas
Aber so eine Umwandlung in ein Objekt ist nicht möglich, oder?

[sap01]

...oder bleibt da nur die getElementById / getElementsByName -Methode
wie
var aaa = "reiheC"
document.getElementById(aaa).innerHTML = irgendwas

??

[Cheatah]

Hi,

In dem Cookie :
reiheC=3;reiheB=15;reiheA=24;

ist das _ein_ Cookie oder sind es drei? Sprich: Hast Du das Semikolon in einer Weise kodiert? Da für Cookiewerte keine bestimmte Kodierung definiert ist, lautete er in dem Fall somit beispielsweise "reiheC=3%3BreiheB=15%3BreiheA=24%3B" oder "reiheC=3|reiheB=15|reiheA=24|", nicht "reiheC=3;reiheB=15;reiheA=24;".

Die Variable "reiheC" ist eine Variable vom Typ "String". -Kann man
den String "reiheC" zu einem Objekt "umtaufen"?

Strings sind Objekte. Eine Verknüpfung zu irgendwelchen anderen Objekten, die in irgendeiner Form mit dem Inhalt "reiheC" zu tun haben könnten, musst Du selbst schaffen. Wie das geht, hast Du beim Vorliegen eines bestimmten von unendlich vielen möglichen Konzepten in Deinem Folgeposting bereits gesagt.

Cheatah

[molily]

Strings sind Objekte.

Strings sind keine Objekte, sondern i.d.R. Primitives. Sie werden lediglich in solche umgewandelt, wenn z.B. durch den Property Accessor Operator ToObject auf ihnen aufgerufen wird. Diese Umwandlung ändert den ursprünglichen String nicht, sondern findet nur zur Evaluierung der Expression statt.

Mathias

[Cheatah]

Hi,

Strings sind keine Objekte, sondern i.d.R. Primitives. Sie werden lediglich in solche umgewandelt, wenn z.B. durch den Property Accessor Operator ToObject auf ihnen aufgerufen wird. Diese Umwandlung ändert den ursprünglichen String nicht, sondern findet nur zur Evaluierung der Expression statt.

ah, dieses Stück der Interna war mir neu, danke für die Info. Ich nehme an, damit hat auch (wahrscheinlich indirekt) der Umstand zu tun, dass Strings u.ä. an Funktionen nicht als Referenz, sondern als Kopie übergeben, liege ich da richtig?

Cheatah

[molily]

Ich nehme an, damit hat auch (wahrscheinlich indirekt) der Umstand zu tun, dass Strings u.ä. an Funktionen nicht als Referenz, sondern als Kopie übergeben, liege ich da richtig?

Jein. Im Grunde wird alles als Referenz übergeben, genau gesagt »by sharing« bzw. »by value where the value is a reference copy«.
</archiv/2011/1/t202555/#m1368388>
http://dmitrysoshnikov.com/ecmascript/chapter-8-evaluation-strategy/

Allerdings besteht bei Primitives einfach keine Möglichkeit, sie »an sich« zu ändern. Man kann höchstens das Binding zwischen Funktionsparameter und Wert lösen, indem man dem Parameter einen neuen Wert zuweist. Damit ändert man aber nicht den Wert in dem Scope, aus dem die Funktion aufgerufen wurde (das wäre ja »by reference«).

Es gibt String-Objects, die im Grunde nur Wrapper um einen internen String-Wert sind. Man spricht von »boxed strings«.

var s = new String('foo');

s hat nun keine Methode, mit der sich der String-Primitive im Object selbst ändern lässt. Sämtliche Methoden geben wieder einen String-Primitive zurück und lassen den im Object gekapselten Wert unberührt.

Daher ist es nicht wirklich sinnvoll und möglich, mit Number-, String- und Boolean-Objects zu arbeiten, man kann nirgends die Vorteile davon nutzen.

Bei Ruby etwa ist das anders, dort gibt es die Unterscheidung zwischen Methoden, die ein neues Objekt erzeugen und solchen, die das vorhandene ändern. Letztere enden auf »!«. Beispiel:

ruby-1.8.7-p302 :006 > s = "Hallo"
 => "Hallo"
ruby-1.8.7-p302 :007 > s.upcase
 => "HALLO"
ruby-1.8.7-p302 :008 > s
 => "Hallo"
ruby-1.8.7-p302 :009 > s.upcase!
 => "HALLO"
ruby-1.8.7-p302 :010 > s
 => "HALLO"

new String("Hallo").toUpperCase() in JavaScript hingegen ändert das vorhandenen String-Object nicht, sondern erzeugt einen neuen Primitive.

Primitives werden wie gesagt im Moment der Auswertung in Objects umgewandelt, damit man auf ihnen die Methoden von String.prototype aufrufen kann. Die erzeugten Objects werden aber weggeworfen. Der Primitive bleibt ein Primitive. Beim nächsten Verwenden als ein Object wird ein neues Object (ein neuer »boxed« String) erzeugt.

var s = "Hallo";  
s.prop = "val"; // Intern wird ToObject aufgerufen, damit die Eigenschaft gesetzt werden kann - das erzeugte Object wird aber weggeworfen  
alert(s.prop); // undefined, weil noch einmal ToObject aufgerufen wird

Mathias

[bonzo400]

<snip>

Bei Ruby etwa ist das anders, dort gibt es die Unterscheidung zwischen Methoden, die ein neues Objekt erzeugen und solchen, die das vorhandene ändern. Letztere enden auf »!«. Beispiel:

ruby-1.8.7-p302 :006 > s = "Hallo"
=> "Hallo"
ruby-1.8.7-p302 :007 > s.upcase
=> "HALLO"
ruby-1.8.7-p302 :008 > s
=> "Hallo"
ruby-1.8.7-p302 :009 > s.upcase!
=> "HALLO"
ruby-1.8.7-p302 :010 > s
=> "HALLO"

<snip>

Schon z.B. String#insert ist ein Gegenbeispiel für diese "Regel".

Das ! im Methodennamen heißt (oder wohl besser: sollte es ursprünglich) einfach nur,
dass diese Methode die 'gefährlichere' von Zweien (die Methode mit ! im Namen und die ohne) ist.

http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist

Conventions in ruby and the principle of least surprise

[molily]

Bei Ruby etwa ist das anders, dort gibt es die Unterscheidung zwischen Methoden, die ein neues Objekt erzeugen und solchen, die das vorhandene ändern. Letztere enden auf »!«
Schon z.B. String#insert ist ein Gegenbeispiel für diese "Regel".

Ich wollte damit nicht behaupten, dass eine Regel existiert, dass sämtliche Methoden, die das Objekt ändern, auf »!« enden. Ich meinte nur, dass der besagte Unterschied zwischen gleichnamigen Methoden, wie ich sie im Beispiel vorgestellt habe, durch »!« gekennzeichnet wird. Freilich wird »!« i.d.R. nur eingesetzt, wenn es eine gleichnamige Methode ohne entsprechende Side-Effects gibt, oder wenn man sonst wie auf die möglichen Side-Effects hinweisen will.

Das Beispiel sollte zeigen, dass es in Ruby überhaupt String-Methoden geben kann, die den String selbst ändern, und dass man zwischen diesen und solchen unterscheiden kann, die einen neuen String zurückgeben. Das ist in JavaScript eben prinzipiell unmöglich, daher habe ich den Vergleich zu Ruby gezogen, um den Unterschied zu illustrieren.

Mathias

[Gunnar Bittersmann]

@@sap01:

nuqneH

-Wenn das geht, könnte man schreiben:
reiheC.innerHTML=irgendwas

Nein, das könnte man nicht. Wie kommst du darauf, ein Objekt namens reiheC
hätte automatisch irgendwas mit dem Elementobjekt eines Elements mit der ID "reiheC" zu tun?

Ich ahne Schlimmes: Du entwickelst mit dem IE. Ich ahne noch Schlimmeres: Du entwickelst für den IE.

Qapla'

[sap01]

Wie kommst du darauf, ein Objekt namens reiheC
hätte automatisch irgendwas mit dem Elementobjekt eines Elements mit der ID "reiheC" zu tun?

im Gegenteil: ich habe beides getrennt, und dargestellt, dass ein Typ String nichts mit einem Elementobjekt zutun hat. GERADE deshalb war meine Frage ja, ob es in JS vielleicht eine Art Konvertierfunktion gibt, um einen Typus String in ein Elementobjekt umzuwandeln, um damit die Möglichkeit zu haben, auf Eigenschaften (z.B. innerHTML) des Elementobjekts zuzugreifen.
Wenn es diese Konvertierfunktion nicht gibt, muss ich immer schreiben ...
var meinLink = "meinLink"
document.getElementById(meinLink).innerHTML = "irgendwas"
Die Zeile (var meinLink = "meinLink") halte ich für doppelt gemoppelt, es gibt zweimal dasselbe Wort, und das ist deshalb sehr umständlich.

[MudGuard]

Hi,

var meinLink = "meinLink"
document.getElementById(meinLink).innerHTML = "irgendwas"
Die Zeile (var meinLink = "meinLink") halte ich für doppelt gemoppelt, es gibt zweimal dasselbe Wort, und das ist deshalb sehr umständlich.

Und warum übergibst Du dann den String nicht direkt an getElementById, sondern schreibst ihn erst in eine Variable?

cu,
Andreas

[Deus Figendi (noReg)]

Aber so eine Umwandlung in ein Objekt ist nicht möglich, oder?

Also erstmal: Ein String ist schon ein Objekt...

Aber so langsam kristallisiert sich heraus, was du überhaupt willst...
Im Grunde spricht nichts gegen getElement(s)By*, ich weiß gar nicht, warum du dich dagegen wehrst.

Aber wenn du unbedingt willst, lässt sich das auch problemlos mit OOP lösen. Erstelle einfach deine Links direkt als JS-Objekte (oder ließ sie ein) und speichere in eine von dir erfundene Eigenschaft den Zähler.

var reiheC = document.getElementById("reiheC");  
reiheC.Zaehler = document.cookie["reiheC"];

(ich weiß gar nicht mehr wie man Cookies in JS handhabt, wahrscheinlich nicht so wie dargestellt, aber ich fand die Benutzung soo unbequem, dass ich es ewig nicht mehr benutzt habe)

Das wäre dann ein erweitertes Node-Objekt, du kannst auch ein eigenes new Object() erstellen und die Node als eigene Eigenschaft rein speichern oder du kannst "ordentliches Prototyping" betreiben ^^

Oder (und das kommt deinem Wunsch wohl am nächsten) du speicherst deine Links einfach in einem assoziartiven Array:

var meineLinks = new Object();  
meineLinks[document.cookie[0]].Zaehler = document.cookie[0];

Oder so... wie gesagt, ich weiß nicht mehr wie man Cookies ausliest :D

[molily]

Also erstmal: Ein String ist schon ein Objekt...

Nein.

Mathias

[Deus Figendi (noReg)]

Also erstmal: Ein String ist schon ein Objekt...

Nein.

Na meinetwegen, ich ging davon aus, weil ich String-Methoden auch direkt auf "freistehende" Strings anwenden kann, so wie:
[Test](javascript:alert("foo".blink());)
alert("foo".blink());
Daher meine Annahme, dass bei var foo = "bar"; ein String-Objekt entstünde und dass bei var baz = /foo/; ein RegExp-Objekt entstünde.
Wenn ich dich richtig verstanden habe passiert das aber erst wenn ich eine Methode darauf anwende _und_ es wird wieder in ein Primitive zurückverwandelt?

Kannst du das für alle JS-Engines sicher sagen?

[molily]

ich ging davon aus, weil ich String-Methoden auch direkt auf "freistehende" Strings anwenden kann, so wie:
alert("foo".blink())

Wie gesagt, das geht, weil hier temporär ein String-Object aus "foo" erzeugt wird.

Daher meine Annahme, dass bei var foo = "bar"; ein String-Objekt entstünde und dass bei var baz = /foo/; ein RegExp-Objekt entstünde.

/foo/ erzeugt tatsächlich ein RegExp-Object.
Alle regulären Ausdrücke sind Objects, es gibt keine entsprechenden Primitives.

Wenn ich dich richtig verstanden habe passiert das aber erst wenn ich eine Methode darauf anwende _und_ es wird wieder in ein Primitive zurückverwandelt?

Ja. Es wird allerdings nicht zurückverwandelt, sondern die Methode erzeugt einfach einen neuen String-Primitive. Das String-Object wird verworfen.

So zumindest ist es definiert und dadurch erklärt sich das Verhalten von Objects vs. Primitives. Die JavaScript-Engines können das natürlich intern optimieren. Intern braucht es also keine Trennung geben, aber »nach außen« für den Programmierer ist die Unterscheidung sehr wirkmächtig.

Kannst du das für alle JS-Engines sicher sagen?

Ja. Das ist eine Grundlage von ECMAScript.

Mathias