JavaScript: verkürzte Schreibweise für mehrfache Objekt-Zugriffe

[Michi]

Hallo,

gibt es eine verkürzte Schreibweise für Fälle, in denen in einem Block Code immer auf das selbe Objekt zugegriffen wird?

xxxxxxxxxxxxxxxxxxxxxxx.methode1();
xxxxxxxxxxxxxxxxxxxxxxx.methode2();
xxxxxxxxxxxxxxxxxxxxxxx.methode3();
xxxxxxxxxxxxxxxxxxxxxxx.methode4();

etc., also vom Prinzip her im Pseudo-Code:

with xxxxxxxxxxxxxxxxxxxxxxx {

.methode1();
.methode2();
.methode3();
.methode4();

}

Gruß Michi

JavaScript: verkürzte Schreibweise für mehrfache Objekt-Zugriffe

[Matti Mäkitalo]

Hi,

gibt es eine verkürzte Schreibweise für Fälle, in denen in einem Block Code immer auf das selbe Objekt zugegriffen wird?

xxxxxxxxxxxxxxxxxxxxxxx.methode1();
xxxxxxxxxxxxxxxxxxxxxxx.methode2();
xxxxxxxxxxxxxxxxxxxxxxx.methode3();
xxxxxxxxxxxxxxxxxxxxxxx.methode4();

Ohne zu wissen, was die Platzhalter beinhalten: nein. Den Fehler, den man hier häufig sieht, ist, dass auf das selbe DOM-Objekt immer wieder mit document.getElement* zugegriffen wird, anstatt dieses in einer Variable zwischenzuspeichern. Dann müsstest du trotzdem noch

variable.methode1();  
variable.methode2();  
// ...

notieren, aber das ist idR kürzer (und performanter) als jedesmal das DOM danach zu durchsuchen.

Eine wirkliche Aufrufkette kannst du nur dann erzeugen, wenn die methoden jeweils this zurückgeben. Standard-DOM Methoden tun dies idR nicht.
jQuery (und wohl auch anderen Frameworks) tun das aber.

$('#myid').show()  
          .css( { 'color' : 'green' })  
// ...  
;

Bis die Tage,
Matti

[Klawischnigg]

Hi there,

Ohne zu wissen, was die Platzhalter beinhalten: nein. Den Fehler, den man hier häufig sieht, ist, dass auf das selbe DOM-Objekt immer wieder mit document.getElement* zugegriffen wird, anstatt dieses in einer Variable zwischenzuspeichern.

Mühsamer vielleicht, aber Fehler? Zumal die komplette Schreibweise bei vernünftiger Verwendung von ID-Bezeichnungen allemal aussagekräftiger ist als eine Variable...

[Vinzenz Mai]

Hallo,

Ohne zu wissen, was die Platzhalter beinhalten: nein. Den Fehler, den man hier häufig sieht, ist, dass auf das selbe DOM-Objekt immer wieder mit document.getElement* zugegriffen wird, anstatt dieses in einer Variable zwischenzuspeichern.

Mühsamer vielleicht, aber Fehler?

wenn man in einer Schleife dasselbe DOM-Objekt immer wieder von neuem bestimmt statt es einmal vor der Schleife zu ermitteln und in einer Variablen zwischenzuspeichern, dann ist dies ein Fehler. Vermutlich der, den Matti meint - und auf den manchmal hingewiesen wird [aktuell z.B. durch Kai].

Freundliche Grüße

Vinzenz

[molily]

Zumal die komplette Schreibweise bei vernünftiger Verwendung von ID-Bezeichnungen allemal aussagekräftiger ist als eine Variable...

Findest du folgendes

document.getElementById('foo-bar').quux();  
document.getElementById('foo-bar').doSomething();  
document.getElementById('foo-bar').doNothing();

aussagekräftiger als dieses?

var fooBar = document.getElementById('foo-bar');  
fooBar.quux();  
fooBar.doSomething();  
fooBar.doNothing();

Mathias

[Klawischnigg]

Hi there,

Findest du folgendes

document.getElementById('foo-bar').quux();

document.getElementById('foo-bar').doSomething();
document.getElementById('foo-bar').doNothing();

>   
> aussagekräftiger als dieses?  
>   
> ~~~javascript

var fooBar = document.getElementById('foo-bar');  

> fooBar.quux();  
> fooBar.doSomething();  
> fooBar.doNothing();

Natürlich nicht. Aber das ist auch der selten erreichte Idealfall. Wie ich es selbst auch vergesse zu tun, bekam  ich es auch schon gelegentlich Code zu bearbeiten, indem es heisst:

  
  
irgendeinevariable=document.getElementById('BUTTON1');  
irgendeineanderevariable=document.getElementById('BUTTON2');  
einedrittevariable=document.getElementById('IRGENDETWAS');  
  

Das ist der Normalfall. Aber Du hast natürlich recht, wenn man aus dem Namen der Variablen die Beziehung zum Objekt hervorgeht, spricht nichts gegen deren Verwendung.
Einen Fehler es anders zu machen vermag ich allerdings trotzdem nicht zu erkennen, es sei denn in dem von Kai erwähnten Schleifenbeispiel, aber er nennt das ja selbst "micro-optimierung"...;)

[Gunnar Bittersmann]

@@Klawischnigg:

nuqneH

irgendeinevariable=document.getElementById('BUTTON1');
irgendeineanderevariable=document.getElementById('BUTTON2');
einedrittevariable=document.getElementById('IRGENDETWAS');

s/.*=document.getElementById('(.*)');/var $1=document.getElementById('$1');/

Qapla'

[Matti Mäkitalo]

Hi,

irgendeinevariable=document.getElementById('BUTTON1');
irgendeineanderevariable=document.getElementById('BUTTON2');
einedrittevariable=document.getElementById('IRGENDETWAS');

s/.*=document.getElementById('(.*)');/var $1=document.getElementById('$1');/

Da bei @id nun auch gerne mal ein (ja, steinige mich!) Minus als Worttrenner verwendet wird und dieses Minus im JS-Kontext nicht als Variablenbezeichner zulässig ist, ist dies ein wenig zu kurz gedacht.

(Dies ist auch der Grund dafür, dass ich Unterstriche zum Trennen nutze statt dem Minus-Zeichen.)

Bis die Tage,
Matti

[Kai345]

[latex]Mae  govannen![/latex]

[document.getElementById]

[...] es sei denn in dem von Kai erwähnten Schleifenbeispiel, aber er nennt das ja selbst "micro-optimierung"...;)

Nein.

Stur lächeln und winken, Männer!
Kai

[Vinzenz Mai]

Hallo,

gibt es eine verkürzte Schreibweise für Fälle, in denen in einem Block Code immer auf das selbe Objekt zugegriffen wird?

ja, das Schlüsselwort http://de.selfhtml.org/javascript/sprache/objekte.htm#with@title=with.

xxxxxxxxxxxxxxxxxxxxxxx.methode1();
xxxxxxxxxxxxxxxxxxxxxxx.methode2();
xxxxxxxxxxxxxxxxxxxxxxx.methode3();
xxxxxxxxxxxxxxxxxxxxxxx.methode4();

Fast.

with xxxxxxxxxxxxxxxxxxxxxxx {

.methode1();
.methode2();
.methode3();
.methode4();

}

with (xxxxxxxxxxxxxxxxxxxxxxx) {  
    methode1();  
    methode2();  
    // ...  
}

with ist übrigens nicht deprecated [molily], auch wenn es Stolperfallen bietet.

Freundliche Grüße

Vinzenz

[molily]

with ist übrigens nicht deprecated [molily], auch wenn es Stolperfallen bietet.

with ist aus heutiger Sicht deprectaed. with wird schon seit Jahren von den ECMAScript-Machern als störend empfunden; dieser Blogpost gibt einen Crockford-Artikel wieder. with erweitert die Scope-Chain durch ein eigenes Objekt und daher ist nicht ersichtlich/eindeutig, wie Bezeichner aufgelöst werden. Das erzeugt unzuverlässigen Code mit schlechter Performance. Daher wird with als schlechter Stil angesehen und es wird davon abgeraten, es zu nutzen. Im Strict Mode von ECMAScript 5 ist es verboten (man kann es nicht verwenden). Es wird aus zukünftigen ECMAScript-Standards höchstwahrscheinlich herausfliegen.

Mathias

[Vinzenz Mai]

Hallo Mathias,

with ist übrigens nicht deprecated [molily], auch wenn es Stolperfallen bietet.

with ist aus heutiger Sicht deprectaed.
Im Strict Mode von ECMAScript 5 ist es verboten (man kann es nicht verwenden). Es wird aus zukünftigen ECMAScript-Standards höchstwahrscheinlich herausfliegen.

danke für den Hinweis. Ich hatte zwar etwas in folgender ...

Das erzeugt unzuverlässigen Code mit schlechter Performance. Daher wird with als schlechter Stil angesehen und es wird davon abgeraten, es zu nutzen.

... Richtung in Erinnerung. Eine kurze (vermutlich zu flüchtige) Suchmaschinen- un Forumsarchivrecherche nach "Javascript, with, deprecated" brachte mir im Archiv hauptsächlich ein paar Hinweise (in Form von AFAIR), dass es deprecated sei - ohne Quellenangabe, Deinen von mir zitierten Beitrag und auch die Suchmaschinenergebnisse waren nicht besonders zufriedenstellend - möglicherweise ist "with" ein Stoppwort.

Freundliche Grüße

Vinzenz

[molily]

Vielleicht hast du nichts gefunden, weil es in ECMAScript nie ein Konzept »deprecated« gab. Das existierte m.W. nur in Netscape-JavaScript-Spezifikationen (Client-Side JavaScript Reference 1.3, Core JavaScript Reference 1.5). Die sind von 1998 bzw. 2000, waren aber nie normativ hinsichtlich des Spachkernes. Netscape hat die Weiterentwicklung ja schon Ende 1996 in die Hände der ECMA gelegt. Erst ECMAScript 5 (2009) hat den besagten Strict Mode eingeführt. Da werden veraltete Sprachfeatures schlicht abgeschaltet bzw. als wirkungslos definiert.

Über die Zukunft von ECMAScript Harmony kann man sich unter http://www.aminutewithbrendan.com/ informieren (von Brendan Eich, dem JavaScript-Erfinder). Da sollen noch härtere Enschnitte gemacht werden, beispielsweise soll das globale Objekt aus der Scope-Chain entfernt werden.

Mathias