Vererbung

[molily]

Hallo zusammen,

Gehe ich richtig in der Annahme, dass folgende Versuche quasi identisch sind:

function Kraftfahrzeug (Fabrikat) { this.Fabrikat = Fabrikat; }
Kraftfahrzeug.prototype.parent = Kraftfahrzeug;
function PKW (Fabrikat) { this.parent(Fabrikat); }
PKW.prototype = new Kraftfahrzeug();
var Golf = new PKW("Volkswagen Golf");
alert(Golf.Fabrikat);

und

function Kraftfahrzeug (Fabrikat) { this.Fabrikat = Fabrikat; }
function PKW (Fabrikat) { this.constructor(Fabrikat); }
PKW.prototype = new Kraftfahrzeug();
var Golf = new PKW("Volkswagen Golf");
alert(Golf.Fabrikat);

Die erste Version findet man öfters. Der Prototyp bekommt eine Referenz auf seinen eigenen Konstruktor als Eigenschaft, im Konstruktor des abgeleiteten Prototyps können dann die dem Konstruktor übergebenen Parameter zum Prototyp durchgereicht werden. So muss this.Fabrikat = Fabrikat und alle weiteren Initialisierungen nur im obersten Konstruktor stehen.
Dieser Umweg erscheint mir aber zu umständlich, wenn es möglich ist, genauso über this.constructor in der Prototype-Chain aufzusteigen. Das sollte sich über mehrere voneinander abstammende Prototypen fortsetzen lassen:

function Menschenartiger (Name) { this.Name = Name; }
function Menschenaffe (Name) { this.constructor(Name); }
Menschenaffe.prototype = new Menschenartiger();
function EchterMensch (Name) { this.constructor(Name); }
EchterMensch.prototype = new Menschenaffe();
function Mensch (Name) { this.constructor(Name); }
Mensch.prototype = new EchterMensch();
var molily = new Mensch("Mathias");
alert(molily.Name);

Kann man das so empfehlen, können die Browser das? Ich habe hier keinen MSIE zum Testen, aber schon Netscape 4 kann es, Opera ab 6 und Firefox 1.0 ebenfalls.
Ferne frage ich mich, ob das doppelte Aufrufen des Prototyp-Konstruktors (new EchterMensch() und this.constructor(Name)) einmal mit und einmal ohne Parameter in der Praxis bei komplexeren Anwendungen Probleme verursachen kann. Falls ja, müsste man tatsächlich das Setzen von Eigenschaften anhand der Parameter in jeder Konstruktorfunktion wiederholen. Ist das gängige Praxis?

Mathias

[Andreas Lindig]

Hallo Mathias,

functioniert bei mir auch im IE ganz gut. Aber wie stellst Du denn sicher, daß man die Eigenschaften richtig überschreiben kann?

Beispiel:

function Menschenartiger (Name) { this.Name = Name; }
function Menschenaffe (Name) { this.constructor(Name); }
Menschenaffe.prototype = new Menschenartiger();
function EchterMensch (Name)
{
   this.constructor(Name);
   //this.Name = "echter Andreas";
}
EchterMensch.prototype = new Menschenaffe();
function Mensch (Name)
{
   this.constructor(Name);
   //this.Name = "Andreas";
}
Mensch.prototype = new EchterMensch();
var molily = new Mensch("Mathias");
alert(molily.Name);

Ich habe in zwei Funktionen einen anderen Namen zugewiesen. In "Mensch()" funktioniert das, in "EchterMensch" nicht. Legt das nicht irgendwie nahe, daß mit dem constuctor-Aufruf gleich direkt zur höchsten Klasse durchgereicht wird, ohne die "Vererbung" der Klassen dazwischen zu beachten?

Gruß, Andreas

[Axel Richter]

Hallo,

Aber wie stellst Du denn sicher, daß man die Eigenschaften richtig überschreiben kann?

Funktioniert das Überschreiben von Eigenschaften bzw. Methoden in JavaScript (Prototyping) überhaupt? Beobachte mal die Reihenfolge des Objekt-Durchlaufs:

function Menschenartiger (Name) { this.Name = Name; }
Menschenartiger.prototype.parent = Menschenartiger

function Menschenaffe (Name) { alert("Menschenaffe extends " + this.parent);this.parent(Name); }
Menschenaffe.prototype = new Menschenartiger();

function EchterMensch (Name) { alert("EchterMensch extends " + this.parent);this.parent(Name); }
EchterMensch.prototype = new Menschenaffe();

function Mensch (Name) { alert("Mensch extends " + this.parent); this.parent(Name); }
Mensch.prototype = new EchterMensch();

var molily = new Mensch("Mathias");
alert(molily.Name);

Übrigens ist das mit der constructor-Syntax genau so.

JavaScript ist eben Kinderkram und keine OOP-Sprache ;-))

viele Grüße

Axel

[Andreas Lindig]

Aber wie stellst Du denn sicher, daß man die Eigenschaften richtig überschreiben kann?

Funktioniert das Überschreiben von Eigenschaften bzw. Methoden in JavaScript (Prototyping) überhaupt?

hehe, das ist eben die Frage. Haben sich ja schon viele versucht JS richtige Vererbung beizubringen... :-)

Beobachte mal die Reihenfolge des Objekt-Durchlaufs:

das ist eben eine der Merkwürdigkeiten mit Prototyp... das bildet im Grunde nur eine nachrangige Eigenschaft des Objekts aber keine Superklasse.

JavaScript ist eben Kinderkram

was ich so nicht unterschreiben würde. Ich schreibe gerade ein schönes Programm in JS und jede andere Sprache wäre hier fehl am Platz, weil sie eben nicht im Brauser läuft :-)

und keine OOP-Sprache ;-))

da stimme ich schon eher zu. Aber mit ein wenig Disziplin - mehrfachNutzung von  Funktionen ausschließen - kann man sich durchauswas zimmern.

Gruß, Andreas

[peterS.]

gruss molily,

function Menschenartiger (Name) {
  this.Name = Name;
}
function Menschenaffe (Name) {
  this.constructor(Name);
}
Menschenaffe.prototype = new Menschenartiger();
...

/*
   zur rekapitulation (fuer mich und andere?) -

bis hierher passiert folgendes:

der prototyp des konstruktors "Menschenaffe" und damit auch der
   prototyp jedes objekts vom typ "menschenaffe" ist ein objekt vom
   typ "menschenartiger" mit der undefinierten eigenschaft "Name".

die eigenschaft "Name" eines "bonobo"-objektes -

var bonobo = new Menschenaffe("bonobo");

- wird zunaechst vom prototypen des objektes bestimmt und ist
   wegen  "Menschenaffe.prototype = new Menschenartiger()"
   unmittelbar am anfang des konstruktoren-aufrufs noch "undefined".
   der konstruktor "Menschenaffe" definiert selbst keine "Name"-
   eigenschaft fuer objekte vom typ "menschenaffe", sondern reicht
   das "Name"-argument wiederum nur an seinen eigenen prototypen-
   konstruktor ("Menschenartiger") weiter. erst an dieser stelle
   der konstruktionskaskade bekommt ein jedes "menschenaffe"-objekt
   seine eigene "Name"-eigenschaft zugewiesen.
 */

...
function EchterMensch (Name) {
  this.constructor(Name);
}
EchterMensch.prototype = new Menschenaffe();

function Mensch (Name) {
  this.constructor(Name);
}
Mensch.prototype = new EchterMensch();

var molily = new Mensch("Mathias");

alert(molily.Name);

...
Ferne frage ich mich, ob das doppelte Aufrufen des Prototyp-
Konstruktors (new EchterMensch() und this.constructor(Name))
einmal mit und einmal ohne Parameter in der Praxis bei
komplexeren Anwendungen Probleme verursachen kann. Falls ja,
müsste man tatsächlich das Setzen von Eigenschaften anhand
der Parameter in jeder Konstruktorfunktion wiederholen.

mit der von Dir im beispiel gewaehlten vorgehensweise bleibst
   Du beschwerdefrei - komplexere Anwendungen verlangen dann
   moeglicherweise nach einem voellig anderen aufbau der
   konstruktoren.

Ist das gängige Praxis?

was praxis ist, weiss ich nicht - ich implementiere zueinander
   in beziehung stehende konstruktoren jedesmal ein wenig anders.

das schoene an javascript ist, dass Du beim stricken von
   komplexen oo-anwendungen ohne einengendes klassen-korsett
   arbeiten darfst. oder anders: kein formalismus nimmt Dich
   an die hand, um Dir den weg aus dem vererbungs-labyrinth
   zu weisen.

Dein beispiel wuerde ich so umsetzen:

var Menschenartiger = function (name) {
     this.name = name;
   };
   var Menschenaffe = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "Menschenartiger";
     this.name = name;
   };
   Menschenaffe.prototype = new Menschenartiger("Menschenaffe");

var EchterMensch = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "Menschenaffe";
     this.name = name;
   };
   EchterMensch.prototype = new Menschenaffe("EchterMensch");

var Mensch = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "EchterMensch";
     this.name = name;
   };
   Mensch.prototype = new EchterMensch("Mensch");

var molily = new Mensch("Mathias");

alert("molily.name = " + molily.name +
     "\n\nmolily.constructor = " + molily.constructor +
     "\n\n(molily.constructor === Mensch) ? " + (molily.constructor === Mensch) +
     "\n(molily.constructor === EchterMensch) ? " + (molily.constructor === EchterMensch) +
     "\n(molily.constructor === Menschenaffe) ? " + (molily.constructor === Menschenaffe) +
     "\n(molily.constructor === Menschenartiger) ? " + (molily.constructor === Menschenartiger) +
     "\n\n(molily instanceof Mensch) ? " + (molily instanceof Mensch) +
     "\n(molily instanceof EchterMensch) ? " + (molily instanceof EchterMensch) +
     "\n(molily instanceof Menschenaffe) ? " + (molily instanceof Menschenaffe) +
     "\n(molily instanceof Menschenartiger) ? " + (molily instanceof Menschenartiger)
   );

by(t)e by(t)e - peterS. - [e-mail]

[Andreas Lindig]

Hallo Peter,

this.constructor = arguments.callee; // ueberschreibt "Menschenartiger";

was macht denn ".callee"?
Immerhin, Dein Aufbau läßt sich nicht so ohne Weiteres von meinem unten genannten Beispiel austricksen.

Gruß, Andreas

[peterS.]

gruss Andreas,

was macht denn ".callee"?

".callee" ist eine eigenschaft des fuer jede funktion vorhandenen
   "arguments"-objekts, die eine referenz auf ebendiese funktion
   enthaelt  -  am beispiel:

var Mensch = function (name) {
     this.constructor = arguments.callee; /* ist aequivalent zu
     this.constructor = Mensch; */
   //alert("(arguments.callee == Mensch) ? " + (arguments.callee == Mensch));
   };

und hier die worte der ECMA spezifikation 262:

10.1.8 Arguments Object

When control enters an execution context for function code, an
     arguments object is created and initialised as follows:

• ...

• A property is created with name callee and property attributes
     { DontEnum }. The initial value of this property is the Function
     Object being executed. This allows anonymous functions to be
     recursive.

• A property is created with name length and property attributes
     { DontEnum }. The initial value of this property is the Number
     of actual parameter values supplied by the caller.

• ...

der fuer mich wichtigste satz lautet:

"This allows anonymous functions to be recursive."

by(t)e by(t)e - peterS. - [e-mail]

[Axel Richter]

Hallo,

das schoene an javascript ist, dass Du beim stricken von
   komplexen oo-anwendungen ohne einengendes klassen-korsett
   arbeiten darfst. oder anders: kein formalismus nimmt Dich
   an die hand, um Dir den weg aus dem vererbungs-labyrinth
   zu weisen.

Nein, es sei denn, Du meinst den letzten Satz sehr ironisch ;-)).

OOP ohne Trennung von Class und Object, also von Beschreibung des Objektes und reeller Objekt-Instanz im Arbeitsspeicher ist nicht sinnvoll. Prototyping ist für mich _keine_ OOP. Es werden einfach nur mehrere Objekt-Instanzen erzeugt, die in Verbindung miteinander stehen. Bei OOP kann aber eine Klasse eine andere erweitern _ohne_, dass ein Objekt der Superklasse vorhanden ist, einfach indem sie die Klasse beerbt. Instanziert wird nur ein Objekt.

Dein beispiel wuerde ich so umsetzen:

Ja, das ist immerhin besser als das vorherige, weil es bei überschriebenen Methoden die richtige[TM] nutzt.

falsch:

function Menschenartiger (Name) { this.Name = Name; }
Menschenartiger.prototype.parent = Menschenartiger

function Menschenaffe (Name) {
 alert("Menschenaffe extends " + this.parent);
 this.parent(Name);
 this.setName = function(text) { this.name = text; alert("Methode von Menschenaffe"); }
}
Menschenaffe.prototype = new Menschenartiger();

function EchterMensch (Name) {
 alert("EchterMensch extends " + this.parent);
 this.parent(Name);
 this.setName = function(text) { this.name = text; alert("Methode von Menschenaffe"); }
}
EchterMensch.prototype = new Menschenaffe();

function Mensch (Name) { alert("Mensch extends " + this.parent); this.parent(Name); }
Mensch.prototype = new EchterMensch();

var molily = new Mensch("Mathias");
alert(molily.Name);

molily.setName("Peter");
alert("molily.name = " + molily.name);

richtiger:

var Menschenartiger = function (name) {
  alert("Menschenartiger");
  this.name = name;
};

var Menschenaffe = function (name) {
  this.constructor = arguments.callee; // ueberschreibt "Menschenartiger";
  alert("Menschenaffe");
  this.name = name;
  this.setName = function(name) { this.name = name; alert("Methode von Menschenaffe"); }
};
Menschenaffe.prototype = new Menschenartiger("Menschenaffe");

var EchterMensch = function (name) {
  this.constructor = arguments.callee; // ueberschreibt "Menschenaffe";
  alert("EchterMensch");
  this.name = name;
  this.setName = function(name) { this.name = name; alert("Methode von EchterMensch"); }
};
EchterMensch.prototype = new Menschenaffe("EchterMensch");

var Mensch = function (name) {
  this.constructor = arguments.callee; // ueberschreibt "EchterMensch";
  alert("Mensch");
  this.name = name;
};
Mensch.prototype = new EchterMensch("Mensch");

var molily = new Mensch("Mathias");
alert("molily.name = " + molily.name);

molily.setName("Peter");
alert("molily.name = " + molily.name);

Du siehst aber an den alerts, dass die Superklassen alle instanziert werden. Alle werden Objekte im Arbeitsspeicher und bleiben dort, bis molily stirbt ;-))(das Objekt molily). So bekommen es die JavaScript-Programmierer hin, dass ein Browser das System mit 100% Prozessor- und 100% Speicherauslastung lahmlegt.

viele Grüße

Axel

PS: Welche Quelle verwendest Du eigentlich jetzt als Spezifikation für JavaScript http://devedge.netscape.com/central/javascript/ ist tot. Mit Google finde ich zwar einige. Die sehen aber alle wie Sekundärquellen aus. http://synchro.net/docs/js/ref/contents.html, http://www.byteshift.de/javascript-1415/CoreReferenceJS15/index.html

[Axel Richter]

Hallo,

falsch:

Sorry, man sollte c&p schon richtig korrigieren ;-))
...

function EchterMensch (Name) {
alert("EchterMensch extends " + this.parent);
this.parent(Name);
this.setName = function(text) {
   this.name = text;

alert("Methode von EchterMensch"); }

}
EchterMensch.prototype = new Menschenaffe();

...
Dann sieht man, dass auch hier die richtige[TM] Methode greift.

Die anderen Bedenken bleiben allerdings bestehen.

viele Grüße

Axel

[peterS.]

gruss Axel,

das schoene an javascript ist, dass Du beim stricken von
   komplexen oo-anwendungen ohne einengendes klassen-korsett
   arbeiten darfst. oder anders: kein formalismus nimmt Dich
   an die hand, um Dir den weg aus dem vererbungs-labyrinth
   zu weisen.

Nein, es sei denn, Du meinst den letzten Satz sehr ironisch ;-)).

durchaus nicht.

OOP ohne Trennung von Class und Object, also von Beschreibung des
Objektes und reeller Objekt-Instanz im Arbeitsspeicher ist nicht
sinnvoll.

warum?

Prototyping ist für mich _keine_ OOP. Es werden einfach nur mehrere
Objekt-Instanzen erzeugt, die in Verbindung miteinander stehen.

das ist nur eine andere art der vererbung, deshalb aber noch lange
   nicht weniger oo.

Bei OOP kann aber eine Klasse eine andere erweitern _ohne_ dass ein
Objekt der Superklasse vorhanden ist, einfach indem sie die Klasse
beerbt. Instanziert wird nur ein Objekt.

hier haben wir die klassisch statische vererbung wo schon zur
   compile-zeit die klassenhierarchie fest (statisch eben) definiert
   wird.

Du siehst aber an den alerts, dass die Superklassen alle instanziert
werden. Alle werden Objekte im Arbeitsspeicher und bleiben dort, bis
molily stirbt ;-))(das Objekt molily).

die dynamischen vererbung baut darauf, dass objekthierarchien waehrend
   der laufzeit geschaffen und _veraendert_ werden koennen. dafuer sind
   prinzipbedingt nun mal objekte (mit Deinen worten bzw. in den termen
   "klassischer oo": instanzen der superklassen) die in ECMAScript dann
   (objekt-)prototypen sind erforderlich.

So bekommen es die JavaScript-Programmierer hin, dass ein Browser
das System mit 100% Prozessor- und 100% Speicherauslastung lahmlegt.

.. uuh .. boes' geflamt. fuer das menschlein, aber auch ohne ein
   einziges objekt vom typ "mensch" wird im beispiel gerade mal ein
   *overhaed* von drei objektprototypen (EchterMensch, Menschenaffe,
   Menschenartiger) erzeugt. bei den dreien bleibt es dann aber auch,
   bis der scripting host stirbt - interpretierte sprachen leben nun
   mal gerne in grosszuegigen raeumen. Aber selbst bei kompexeren
   anwendungen zwingst Du den browser nicht ueber vererbung in die knie.

vielen JavaScript-programmierern gelingt dies hingegen muehelos ueber
   DOM mit unreferenzierten "document.getElementById"-orgien.

das von Dir erweiterte bsp. liesse sich dank des prototypen-konzepts
   wiederum wie folgt vereinfachen:

var Menschenartiger = function (name) {
     alert("Menschenartiger");
     this.name = name;
   };
   Menschenartiger.prototype.setName = function (name) { // ein setter-prototyp genuegt;
     this.name = name;
     alert("prototypen methode: " + arguments.callee);
   };

var Menschenaffe = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "Menschenartiger";
     alert("Menschenaffe");
     this.name = name;
   //durch den prototypen schon implementiert:
   //this.setName = function(name) { this.name = name; alert("Methode von Menschenaffe"); }
   };
   Menschenaffe.prototype = new Menschenartiger("Menschenaffe");

var EchterMensch = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "Menschenaffe";
     alert("EchterMensch");
     this.name = name;
   //durch den prototypen schon implementiert:
   //this.setName = function(name) { this.name = name; alert("Methode von EchterMensch"); }
   };
   EchterMensch.prototype = new Menschenaffe("EchterMensch");

var Mensch = function (name) {
     this.constructor = arguments.callee; // ueberschreibt "EchterMensch";
     alert("Mensch");
     this.name = name;
   };
   Mensch.prototype = new EchterMensch("Mensch");

var molily = new Mensch("Mathias");
   alert("molily.name = " + molily.name);

molily.setName("Peter");
   alert("molily.name = " + molily.name);

viele Grüße

danke,

PS: Welche Quelle verwendest Du eigentlich jetzt als Spezifikation
für JavaScript http://devedge.netscape.com/central/javascript/
ist tot. Mit Google finde ich zwar einige. Die sehen aber alle wie
Sekundärquellen aus. http://synchro.net/docs/js/ref/contents.html,
http://www.byteshift.de/javascript-1415/CoreReferenceJS15/index.html

ich nehme sowohl die

deutsche ausgabe der 4. englischen auflage von David Flanagans
   Javascript-bibel "JavaScript. Das umfassende Referenzwerk."
   O'REILLY / Juni 2002 / ISBN: 3897213303

sowie das nach meinem geschmack gelungenere

"JavaScript Developer's Dictionary" von Alexander J. Vincent
   SAMS / Juni 2002 / English / ISBN: 0672322013

als auch die "ECMAScript Language Specification" (Standard ECMA-262) zur hand.

by(t)e by(t)e - peterS. - [e-mail]

[Axel Richter]

Hallo,

So bekommen es die JavaScript-Programmierer hin, dass ein Browser
das System mit 100% Prozessor- und 100% Speicherauslastung lahmlegt.
   .. uuh .. boes' geflamt.

*g* In _diesem_ Forum wohl schon.

Aber selbst bei kompexeren anwendungen zwingst Du den browser nicht ueber vererbung in die knie.

Ja, nicht alleine dadurch. Beispiel gefällig?
http://www.webreference.com/programming/javascript/gr/column5/2.html

ACHTUNG! keine wichtigen Fenster offen haben!
http://www.webreference.com/programming/javascript/gr/column5/AutoComplete.htm

vielen JavaScript-programmierern gelingt dies hingegen muehelos ueber
   DOM mit unreferenzierten "document.getElementById"-orgien.

Das ist auch wahr.

das von Dir erweiterte bsp. liesse sich dank des prototypen-konzepts
   wiederum wie folgt vereinfachen:

Menschenartiger.prototype.setName = function (name) { // ein setter-prototyp genuegt;

Ja, danke für den Hinweis, ich bin eben auf meine Java-Klassen und deren Prinzipien fixiert.

Es wird schon so sein, man kann auch mit JavaScript richtig[TM] programmieren, wenn man es richtig[TM] macht ;-)).

ich nehme sowohl die

Danke für die Links.

viele Grüße

Axel

[Andreas Lindig]

selbst bei kompexeren anwendungen zwingst Du den browser nicht ueber vererbung in die knie.

vielen JavaScript-programmierern gelingt dies hingegen muehelos ueber
DOM mit unreferenzierten "document.getElementById"-orgien.

könntes Du das bitte noch erläutern? Was meint "unreferenziert"? Ich schreibe gerade ein umfangreicheres JS-Programm und muß da jede Menge Objekte - auch über 'document.getElementById' angesprochen - geleichzeitig verändern. Natürlich will ich das möglichst performant gestalten.

und Danke für die Literatur-Tips.

Gruß, Andreas

[peterS.]

gruss Andreas,

vielen JavaScript-programmierern gelingt dies hingegen muehelos ueber
DOM mit unreferenzierten "document.getElementById"-orgien.

könntes Du das bitte noch erläutern? Was meint "unreferenziert"? Ich schreibe
gerade ein umfangreicheres JS-Programm und muß da jede Menge Objekte -
auch über 'document.getElementById' angesprochen - geleichzeitig verändern.
Natürlich will ich das möglichst performant gestalten.

entschuldige bitte die schwammige formulierung - jetzt wo Du es sagst,
   faellt es mir auch auf. mit "unreferenziert" wollte ich mich in diesem fall
   um mehrere (neben)saetze druecken und eigentlich folgendes sagen:

es gibt immer noch genug leute, die fuer jede eigenschaft eines knotens,
   die sie innerhalb einer sequenz setzen wollen, jedesmal aufs neue mit
   "document.getElementById" auf dieses objekt losgehen, anstatt einmalig
   einer variablen die referenz auf den gewuenschten knoten zuzuweisen,
   um dann mit ebendieser variablen weiterzuarbeiten.

boese:
     document.getElementById("objId").style.backgroundColor = "#...";
     document.getElementById("objId").style.color = "#...";
     document.getElementById("objId").style.display = "block";
     document.getElementById("objId"). ... ;

wenn schon "document.getElementById", dann besser so:
     var nodeObj = document.getElementById("objId");
     nodeObj.style.backgroundColor = "#...";
     nodeObj.style.color = "#...";
     nodeObj.style.display = "block";
     nodeObj. ... ;

"document.getElementById" ist richtig teuer, denn diese methode hangelt
   sich jedes mal aufs neue durch den gesamten elemente-baum.
   ueberhaupt ist "document.getElementById" nur in sehr wenigen faellen die
   einzige moeglichkeit, um an einen knoten zu kommen.
   vorher sollte man ruhig die guten alten collections wie "doument.images",
   "document.forms" oder "document.links" bemuehen.
   den rest erschlaegt man eigentlich immer kostenguenstiger mit
   "document.getElementsByTagName([string tagname])[[string idOrName]]".

wenn man z.b. div-soup hat und mehrere eigenschaften einer groesseren
   anzahl dieser divs setzen moechte, sollte man sich sowohl einer referenz
   auf die "HTMLDivElement"-collection als auch einer referenz auf das jeweils
   mehrfach zu bearbeitende "HTMLDivElement" bedienen:

var divColl = document.getElementsByTagName("div"); // alle divs im dokument;
   var nodeObj = divColl["objIdOrName01"];
 //nodeObj.style. ... eigenschaft setzen;
 //nodeObj.style. ... eigenschaft setzen;
   nodeObj = divColl["objIdOrName02"];
 //nodeObj.style. ... eigenschaft setzen;
 //nodeObj.style. ... eigenschaft setzen;
 //usw.

an dieser stelle sei noch erwaehnt, dass die aus alten msie-tagen bekannte
   und viel genutzte "document.all"-collection auch mit den mitteln des w3c-DOM
   abgebildet werden kann - Thomas Meinike hat dies meines wissens nach das
   erstemal im dezember 2002 ins forum getragen, als er eine neue funktion
   vorstellte. das aequivalent lautet: 'document.getElementsByTagName("*")'.

by(t)e by(t)e - peterS. - [e-mail]

[Axel Richter]

Hallo,

wenn schon "document.getElementById", dann besser so:
     var nodeObj = document.getElementById("objId");
     nodeObj.style.backgroundColor = "#...";
     nodeObj.style.color = "#...";
     nodeObj.style.display = "block";
     nodeObj. ... ;

Ergänzung:
Objekte sollten, wenn sie nicht mehr benötigt werden, wieder freigegeben werden. Wenn also alles, wozu nodeObj benötigt wurde, erledigt ist, kann
nodeObj = null;
gesetzt werden.

Das ist natürlich nur wichtig, wenn es sich um Objekte im Scope window handelt, also solche, die außerhalb von Funktionen liegen oder innerhalb von Funktionen ohne var-Deklaration definiert wurden. Objekte, die nur innerhalb von Funktionen gültig sind, sterben mit Beendigung der Funktion. Die Frage "var oder nicht var" ist also auch eine, die auf Performance von JavaScript im Browser Einfluss hat.

viele Grüße

Axel

[Andreas Lindig]

vielen Dank euch Beiden.
hab mir heute erstmal das empfohlene deutsche Buch zur Ansicht bestellt...

Gruß, Andreas

[Andreas Lindig]

hab mir heute erstmal das empfohlene deutsche Buch zur Ansicht bestellt...

hab mir das Buch heute gekauft. Ist ja ziemlich dick: 1000 Seiten für 50 Euro, das macht 5 Cent pro Seite. Ich finde das geht. Schreib mal einer eine Seite für 5 Cent Lohn voll...

Scheint wirklich gut, weil es eben die Prinzipien auch erklärt. Wollte eigentlich nur Anfängern abraten - fürs Archiv. Für Anfänger ist das zu sehr Referenz.

Gruß, Andreas