nicht angemeldet
Globale Variablen in einer function erzeugen.
Hallo,
ich hatte das Problem, daß ich Objekte oder auch Variablen von einer
Funktion global sichtbar erzeugen wollte.
Dabei habe ich herausgefunden, daß Initialisierungen von Variablen
innerhalb einer Funktion ohne ein "var" davor auch global sichtbar sind
und habe das dann bei meinem JavaScript-Problem kräftig benutzt.
z.B:
eval(varname + "_bild = 0;");
oder:
eval(name + "_objekt = new testObject('layer1')");
Das hat hervorragend funktioniert!
Nun zum Problem: Verletze ich damit irgentwelche JavaScript Regeln?
Ich habe verschiedenen Tutorien, unter anderem das von Netscape
(CoreGuideJS15), nach dem Thema Variablendeklaration und -sichtbarkeit
durchgeforstet, und dort stand dann, man könne das "var" vor der
Deklaration globaler Variablen weglassen, bei lokalen muß es immer dabei
sein.
Das habe ich ja offensichtlich verletzt, wenn ich bei der Deklaration von
Variablen innerhalb einer Funktion das "var" weglasse.
Weiterhin bleibt aber in diesen Tutorien bei der Definition von Objekten
vor den Methoden und Eigenschaften das "var" immer weg, also z.B:
function testObject()
{
this.name;
this.methode1 = ausfuehren;
this eigenschaft1 = 0;
}
Wie funktioniert das nun richtig, und wer setzt diesen Sachverhalt fest
...naja und wo kann man dazu mal was definitives nachlesen?
Danke für Eure Antwort
Simy
-
Hallo,
eval(name + "_objekt = new testObject('layer1')");
Das hat hervorragend funktioniert!durchgeforstet, und dort stand dann, man könne das "var" vor der
Deklaration globaler Variablen weglassen, bei lokalen muß es immer dabei
sein.das "var" kann man eigentlich immer weglassen, aber wenn man es bei lokalen
Variablen weglässt bleibt die Variable nicht mehr lokal, sie ist dann z.B.
nicht nur in einer for-Schleife gültig sondern auch ausserhalb oder man
bekommt den Inhalt einer globalen Variable auch "lokal".Grüsse
Cyx23
-
Hallo,
das "var" kann man eigentlich immer weglassen, aber wenn man es bei lokalen
Variablen weglässt bleibt die Variable nicht mehr lokal, sie ist dann z.B.
nicht nur in einer for-Schleife gültig sondern auch ausserhalb oder man
bekommt den Inhalt einer globalen Variable auch "lokal".Grüsse
Cyx23Ja...das habe ich ja bereits gemerkt und ausgenutzt...mein Problem ist, daß
ich nicht weiß, ob das nun korrektes Javascript ist, da ich diesen Vorgang
nirgens dokumentiert gefunden habe.
Ich wollte halt ein Script schreiben, was auch bei anderen Browsern
funktioniert. Wenn das, was ich da tue nun nur auf dem Netscape Navigator
und Internet Explorer funktioniert, und nicht z.B. auch auf Opera, dann
würde ich mir da lieber etwas anderes ausdenken, obwohl die Lösung recht
elegant ist.Gruß, Simy
-
Hallo,
Ich wollte halt ein Script schreiben, was auch bei anderen Browsern
funktioniert. Wenn das, was ich da tue nun nur auf dem Netscape Navigator
und Internet Explorer funktioniert, und nicht z.B. auch auf Opera, dann
würde ich mir da lieber etwas anderes ausdenken, obwohl die Lösung recht
elegant ist."var" gehört zum Vorgang der Deklaration, ist aber nicht nötig.
"var" ist bei lokalen Variablen möglich, z.B. um bei for-Schleifen
o.ä. den gleichen Bezeichner "i" zu verwenden, "var" ist aber
nicht erforderlich .
Es wird oft behauptet es wäre guter Stil "var" beim Deklarieren zu
benutzen, sowie Variablen überhaupt vor der Benutzung zu deklarieren.Zumindest kann es die Übersichtlichkeit verbessern.
Grüsse
Cyx23
-
Hallo Cyx23
"var" gehört zum Vorgang der Deklaration, ist aber nicht nötig.
[...]
Zumindest kann es die Übersichtlichkeit verbessern.Nunja, wie ich schon schrieb, ob ich's weglasse oder nicht ist ja auch qualitativ ein Unterschied!
In einer Funtion deklariert ohne "var" heißt: global verwendbar.
Das heißt dann auch, daß evtl. bei erneutem Aufruf derselben Funktion, die Variable schon vorhanden ist, und zwar mit einem evtl. unerwarteten Inhalt!
Damit hat das für mich nichts mehr mit vebesserter Übersichtlichkeit zu tun, sondern ich meine, daß man da sehr fein unterscheiden sollte.
Oder sehe ich das nicht richtig?Simy
-
Es reicht !
"var" gehört zum Vorgang der Deklaration, ist aber nicht nötig.
[...]
Zumindest kann es die Übersichtlichkeit verbessern.das steht im [...] was du unterschlagen hast :
"var" ist bei lokalen Variablen möglich, z.B. um...
und in meinem vorherigen posting :
'aber wenn man es bei lokalen Variablen weglässt bleibt die Variable nicht mehr lokal,'
also fang hier nicht an Postings durch auszugsweise Zitate zu manipulieren !
-
Es reicht !
Hmm... tut mir leid, hab' Dich wohl nicht richtig verstanden.
Ich glaube es ist langsam klar.Eigentlich war mein Anliegen ja nur eine schriftliche Bestätigung des nunmehr reichlich besprochenen Sachverhalt, aber anscheinend ist dieser eine klare Tatsache.
Danke für Deine Bemühungen.
Simy
-
-
-
-
-
-
Hi,
Das habe ich ja offensichtlich verletzt, wenn ich bei der Deklaration von
Variablen innerhalb einer Funktion das "var" weglasse.Wieso hast du "das" verletzt?
Um Deinen letzten Satz sinngemäß zu zitieren: Du hast innerhalb einer Funktion durch Weglassen von "var" einfach eine globale statt einer lokalen Variable erzeugt.Weiterhin bleibt aber in diesen Tutorien bei der Definition von Objekten
vor den Methoden und Eigenschaften das "var" immer weg, also z.B:function testObject()
{
this.name;
this.methode1 = ausfuehren;
this eigenschaft1 = 0;
}Wie funktioniert das nun richtig, und wer setzt diesen Sachverhalt fest
1. Nun ja, eine Methode sollte sinnvollerweise keinen Bezeichner "var" haben...
2.In JS brauchen Objekteigenschaften - unabhängig von der Tatsache, dass JS eben auf diese Weise implementiert ist - keinen "var"-Bezeichner. Grund: Alle Objekteigenschaften sind per Definition Variablen, außer ihnen werden explizit Funktionen zugewiesen (was diese dann zu Objektmethoden macht).
Grüße,
Martin-
- Nun ja, eine Methode sollte sinnvollerweise keinen Bezeichner "var" haben...
Ähh...wieso nicht? Normalerweise sollte alles in einer Funktion, was Variable ist, ein "var" davor haben, zumindest wenn ich dem CoreGuideJS15 von Netscape trauen soll.
Klar hier bei dem SELFHTML-Tutorial macht man es so. Aber irgentwie hatte ich den Eindruck, man macht das bei Objekt-Eigenschaften und -Methoden einfach so, aber keiner weiß warum.Gruß, Simy
-
Hi Simy,
hier gibt es wohl ein paar Missverständnisse.
Beispiel:
<script language="JavaScript">function TestObj(einName){
/*
Dies ist eine Funktion mit besonderer Bedeutung. Da durch
sie ein Objekt angelegt oder "konstruiert" wird, bezeichnet man sie auch als den "Konstruktor" des Objekts.
*/
this.name = einName;
/*
Die Eigenschaft 'name' dieses Objekts ist eine Variable, der in diesem Fall der Wert der Parametervariablen 'einName' zugewiesen wird. 'name' ist implizit eine Variable, auch OHNE bei der Deklaration/Initialisierung den Bezeichner "var" verwendet zu müssen!
Die Parametervariablen sind übrigens auch LOKALE Variablen.
*/this.GibNamen = GibNamen; // (ohne Klammern)
this.SetzeNamen = SetzeNamen;
/*
Die Eigenschaft 'GibNamen' dieses Objektes ist implizit eine Methode, da ihr - und nur deswegen - eine Funktion zugewiesen wurde.
*/
alert(this.GibNamen());var neuerName = "Müller";
// dies ist eine lokale Variable, nur gültig in diesem Konstruktor oder allgemein Anweisungsblock.this.SetzeNamen(neuerName);
// oder: this.name = neuerName;
alert(this.GibNamen());// ACHTUNG: jetzt definierst Du eine GLOBALE Variable
globalerName = "Schulz";// ACHTUNG: jetzt definierst Du eine LOKALE Variable
var lokalerName = "Schmitt";} // end constructor
function GibNamen(){
return this.name;
}function SetzeNamen(einName){
this.name = einName;
}// Script-"Body"
/*
Jetzt wird eine Instanz des Objektes erzeugt, dessen Eigenschaften zuvor im Konstruktor definiert wurden.
*/
test = new TestObj("Paul Meier");
/*
test ist eine globale Variable, genauso geht:
var test = new TestObj("Paul Meier");
siehe dazu Thomas Mells Posting
*/// jetzt greifst Du auf die GLOBALE Variable zu, die du im Konstruktor deklariert und initialisiert hast.
test.SetzeNamen(globalerName);
alert(test.GibNamen());// jetzt greifst Du auf die LOKALE Variable zu, die du im Konstruktor deklariert und initialisiert hast.
test.SetzeNamen(lokalerName);
// SO, JETZT MÜSSTEST DU EINEN SCRIPTFEHLER ERHALTEN HABEN ;-)))</script>
vielleicht ist es Dir jetzt etwas klarer geworden.
Grüße,
Martin -
Moin!
- Nun ja, eine Methode sollte sinnvollerweise keinen Bezeichner "var" haben...
var ist ein reserviertes Wort und kann nicht als Bezeichner verwendet werden.
Ähh...wieso nicht? Normalerweise sollte alles in einer Funktion, was Variable ist, ein "var" davor haben, zumindest wenn ich dem CoreGuideJS15 von Netscape trauen soll.
Eigenschaften und Methoden eines Objekts sind aber keine "normalen" Variablen. Es ist explizit falsch, vor eine Eigenschaftszuweisung "var" zu schreiben:
JavaScript Error: [unknown origin]:
missing ; before statement.
x = new Object(); x.laber = 3; var x.tratsch = 5; alert(x.laber+x.tratsch);
....................................^Wie Du dem JS Guide entnehmen kannst, sind Objekte nichts anderes als assoziative Arrays. Obiges ist also aequivalent zu
x["laber"] = 3;
var x["tratsch"] = 5; // und das ist natuerlich nicht sinnvollDie einzige Variable hier heisst x. Nicht laber, nicht tratsch.
So long
-
-
Hallo,
das meisste hast du schon richtig erkannt:
Alle Variablen sind global wenn sie nicht mit "var" deklariert sind, egal wo dies geschieht.
Alle mit var deklarierten Variablen sind innerhalb eines Blocks (zwischen { } ) lokal, dabei ist es egal ob es sich um eine function, if - Abfrage oder einer Schleife handelt.
Mit var deklarierte Variablen im Scriptkoerper sind eigentlich lokal im Bezug auf diesen Koerper. Da sich aber alle anderen Bloecke in diesen Koerper befinden, koennen diese auf die Variable zugreifen - somit ist sie letztendlich global.Nun zu den Objekten:
function testObject()
{
this.name;
}this.name ist eine Eigenschaft der Klasse "testObject". Wenn du aus dieser Klasse mehrer Objekte instanzierst, existiert diese Eigenschaft entsprechend oft und kann jeweils einen anderen Wert enthalten.
Wenn man in einer Klasse var name= "xyz" schreibt, hat man eine Klassenvariable (keine Eigenschaft) die nur in dieser Klasse sichtbar ist - sie ist nicht ueber das Objekt zu erreichen.
Wenn man in der Klasse nur name="xyz" schreibt dann verfuegt man ueber eine ganz normal globale Variable ohne Bezug auf eine Klasse oder einem Block.viele Gruesse
Thomas Mell-
Hallo Thomas,
Das war richtig gut, hat mir den Eindruck von Korrektheit gegeben und Entspricht 100%ig meinen Beobachtungen...
Aber woher hast Du das? Wo ist das genauso spezifiziert?Gruß Simy
-
Hi,
Wo ist das genauso spezifiziert?
"Das" ist einfach so (in fast jeder Sprache), das gehoert zu den Grundlagen der Programmierung und hat nichts "spezielles" bei Javascript. Ob du dir C++, VisualBasic, Perl, Java etc. ansiehst - es ist immer das selbe (prinzipiell). In jeder Sprache gibt es lokale und globale Variablen, ob sie nun mit var, local, privat oder sonst wie deklariert werden ist letztendlich Wurst. Und was Methoden und Eigenschaften angeht, ist dies auch fast immer Identisch (natuerlich nur bei OOP-Sprachen).
viele Gruesse
Thomas Mell
-
-
Moin!
Alle Variablen sind global wenn sie nicht mit "var" deklariert sind, egal wo dies geschieht.
Schoen, dass endlich mal jemand wirklich weiss, was die Begriffe global und lokal bedeuten. Insbesondere ist eine Variable nicht lokal, nur weil ich sie innerhalb einer Funktion das erste mal benutze, sondern nur deshalb, weil ich sie dort mit var deklariere.
Nun zu den Objekten:
function testObject()
{
this.name;
}
this.name ist eine Eigenschaft der Klasse "testObject".Nicht unbedingt. Nur wenn Du ein Objekt mit
var x = new testObject();
erzeugst. testObject kann aber auch eine ganz normale Methode eines (andersnamigen) Objekts sein. Wenn man dann x.testObject() aufruft, zeigt this ebenfalls korrekt auf x.Wenn man in einer Klasse var name= "xyz" schreibt, hat man eine Klassenvariable (keine Eigenschaft) die nur in dieser Klasse sichtbar ist - sie ist nicht ueber das Objekt zu erreichen.
Man kann sowas nicht "in einer Klasse" schreiben. Man kann sowas in einer Funktion schreiben, die als Methode einer Klasse dient. Das ist dann aber eine ganz normale funktionslokale Variable und hat nichts mehr mit der Klasse zu tun.
Wenn man in der Klasse nur name="xyz" schreibt dann verfuegt man ueber eine ganz normal globale Variable ohne Bezug auf eine Klasse oder einem Block.
Stimmt. Nur wenn man
objekt.eigenschaft = "irgendwas";
schreibt, wobei fuer objekt innerhalb einer Klassenmethode das reservierte Wort this stehen kann, greift man auf eine Objekteigenschaft zu.So long
-
-
Hallo,
irgentwie driftet das Thema in eine Richtung, die ich nicht ganz beabsichtigt habe.(Wurde mir irgentwie seit des letzten Postings von Cyx23 klar.)
Ich hatte das Problem lokal/global bereits GELÖST(!).
Es ist nett und hilfreich, den angesprochenen Sachverhalt nochmal klarzustellen und zu erläutern, aber das eigentliche Problem ist doch:
Wo steht das geschrieben?Ich will das deswegen wissen, da ich selten in einer Programmiersprache die Möglichkeit habe, mitten im Programmablauf Variablen zu allokieren und diese dann auch noch mittels eines BELIEBIGEN(!) Strings zu bennenen. Wie gesagt: während des Ablaufs.
In C++ ist so etwas tatsächlich NICHT möglich, soweit ich weiß.
(Kann ja gar nicht; C++-Code kann nicht während des Ablaufs noch generiert und ausgeführt werden.)Die Möglichkeit innerhalb einer Funktion ohne das "var" auszukommen und damit dann aber etwas global zu bewegen ist, trotz daß das allen hier wohl bekannt scheint, nirgens wirklich richtig dokumentiert.
Und das sollte das eigentliche Thema sein.
Also: Wenn jemand wirklich weiß, wo sowas steht, dann bitte auf ein Neues.Dankeschön.
Gruß, Simy
PS: Nichts für ungut; ich möchte niemenden ärgern, es ist mir ein echtes Anliegen.
-
Hi again!
irgentwie driftet das Thema in eine Richtung, die ich nicht ganz beabsichtigt habe.(Wurde mir irgentwie seit des letzten Postings von Cyx23 klar.)
Umwege erhoehen die Ortskenntnis.
Die Möglichkeit innerhalb einer Funktion ohne das "var" auszukommen und damit dann aber etwas global zu bewegen ist, trotz daß das allen hier wohl bekannt scheint, nirgens wirklich richtig dokumentiert.
Sollte das im JS1.5-Guide nicht mehr drinstehen? Kann ich mir nicht vorstellen. Im JS1.3-ClientGuide und -Ref steht es jedenfalls:
http://developer.netscape.com/docs/manuals/js/client/jsguide/ident.htm#1008330
http://developer.netscape.com/docs/manuals/js/client/jsref/stmt.htm#1066604Zugegeben, es steht nicht so richtig deutlich dort, aber mit ein bisschen Ueberlegung kommt man drauf.
So long
-
Ja (Beckerfaust) :)
Danke Calocybe, daß war's was ich suchte...ich mußte nur mit der Nase draufgestoßen werden...naja und 2+2=4...
Danke
Mit freundlichem Gruß
Simy
-
Hallo Calocybe
nach der Menschelei (Posting vorher) zur Info:
Im JS1.5-Guide (CoreGuideJS15) steht tatsächlich:[...]Using var to declare a global variable is optional. However, you must use var to declare a variable inside a function.
Steht in:
http://developer.netscape.com/docs/manuals/js/core/jsguide15/ident.html#1008330Tja und das ist tatsächlich auch der Hauptgrund, warum es mich halt so umgehauen hat, und ich mit dieser Postingreihe überhaut angefangen habe...
Ich bin ja nicht darauf gekommen das ein Version füher...Jetzt habe ich sogar noch die Version 1.4 gefunden...ich denke jetzt habe ich genug...
Danke nochmal,
Simy
-
Hi again!
[...]Using var to declare a global variable is optional. However, you must use var to declare a variable inside a function.
Steht in:
http://developer.netscape.com/docs/manuals/js/core/jsguide15/ident.html#1008330IMHO drueckt folgender Abschnitt, der auch noch unter der von Dir genannten URL steht, am besten aus, was Sache ist:
Variable Scope
When you set a variable identifier by assignment outside of a function, it is called a global variable, because it is available everywhere in the current document. When you declare a variable within a function, it is called a local variable, because it is available only within the function.
Using var to declare a global variable is optional. !!>>> However, you must use var to declare a variable inside a function. <<<!!Unklar gelassen wird hier lediglichm was passiert, wenn man innerhalb einer Funktion eine Variablenzuweisung ohne var macht. (Naemlich dass die Variable dann global wird.)
Naja, wuerde JS sich einfach verhalten wie eine vernuenftige Sprache und immer auf der ordentlichen Deklaration von Variablen bestehen, haetten wir das Problem nicht. (Aehnliches gilt fuer die hirnverbrannte automatische Typenumwandlung.)
So long
-
Hallo Calocybe,
ich wollte eigentlich keinen mehr draufsetzen, aber irgentwie habe ich den Eindruck, Du verstehst mich gut:
Unklar gelassen wird hier lediglichm was passiert, wenn man innerhalb einer Funktion eine Variablenzuweisung ohne var macht. (Naemlich dass die Variable dann global wird.)
Eben: unklar...aber nun das hier:
Naja, wuerde JS sich einfach verhalten wie eine vernuenftige Sprache und immer auf der ordentlichen Deklaration von Variablen bestehen, haetten wir das Problem nicht. (Aehnliches gilt fuer die hirnverbrannte automatische Typenumwandlung.)
Das mit der automatischen Typumwandlung macht zwar einiges einfacher...aber ich find's auch bekloppt. Wenn man ein paar Postings weiter früher (unten) guckt, gibt es auch zu viele Probleme damit:
Marfi:(JAVASCRIPT) mit Variablen rechnen http://www.teamone.de/selfaktuell/forum/?m=145205&t=27856
Wenn man in einer Computersprache das Problem hat 2 und 2 zusammenzuzählen ... &%/$%&/ ... bekloppt!ABER: Mit dieser global-Geschichte innerhalb einer Funktion...sehe ich anders.
Ich habe damit eben genau die Möglichkeit dynamisch irgentwelche Variablen zu erzeugen.
In meinem Fall habe ich eine JS-Datei geschriebn, womit man nette Menus erzeugen kann, und zwar in Tabellenform.
Man schreibt die Menupunkte in eine normale HTML-Tabelle und umfasst sie mit einem div-Tag, dem man einen Namen gibt, z.B. id="Menu_1"
Das Javascript nun erzeugt bei einmaligem: init("Menu_1") sämtliche Variablen, merkt sich also sämtliche Daten und macht ein auf- und zupklappendes Menu (auf MousOver oder MouseOut) aus der Tabelle, die dann sogar frei positionierbar ist.
Das schöne daran ist, daß der User irgentwas in HTML bauen kann, und nur noch einmal am Ende einen inti(); - Befehl schreiben muß und - alles funzt.
Der Benutzer hat das Gefühl, einen einfachen Befehl zu benutzen, ohene irgentwelche besonderen Kenntnisse von JavaScript...und den ganzen Problemen gie man mit Variablen haben kann.
Diese Sache könnte ich sonst nur machen, indem ich den User vorher noch angeben lassen muß, wieviele Menus er für die Seite braucht, und zwar in der Form:
var menuArray = new Array(5) // für 5 Menus
oder so ähnlich. Das ist irgentwie nicht elegant, und kapselt auch das JavaScript nicht ordentlich ab.Naja, ich hoffe, es war irgentwie interessant. :S
Großes Faszit aus dem Ganzen:
Ich darf das so machen; das Script ist einfach zu benutzen...und ist JavaScript-konform.
So long
Genau: Bis zum nächsten Mal
Gruß, Simy
-
Re!
ich wollte eigentlich keinen mehr draufsetzen, aber irgentwie habe ich den Eindruck, Du verstehst mich gut:
Ich finde Thread-Drifts gut. :-)
Das mit der automatischen Typumwandlung macht zwar einiges einfacher...aber ich find's auch bekloppt. Wenn man ein paar Postings weiter früher (unten) guckt, gibt es auch zu viele Probleme damit:
Marfi:(JAVASCRIPT) mit Variablen rechnen http://www.teamone.de/selfaktuell/forum/?m=145205&t=27856Ja, und das ist eine der meistgestellten Fragen hier im Forum.
ABER: Mit dieser global-Geschichte innerhalb einer Funktion...sehe ich anders.
Ich habe damit eben genau die Möglichkeit dynamisch irgentwelche Variablen zu erzeugen.
[...]Klar hat das auch seine Vorteile - unwidersprochen. Dein Beispiel laesst sich aber auch leicht anders realisieren, da JS assoziative Arrays kennt. Deklariert man einen Container, der z.B. alle globalen Variablen aufnehmen soll:
var globals = [ ]; /* <==> var globals = new Array(); */
dann kann man dynamisch mit
var tmp;
globals["menu_1"] = [ ];
tmp = globals["menu_1"]["mouseoverimg"] = new Image();
tmp.src = "/images/...gif";
usw. sehr schoen seine dynamischen Daten aufbauen. Dann kann man z.B. einen kompletten "Unterzweig" an eine Funktion uebergeben:
funktion(globals["menu_1"]);
die dann mit arg["mouseoverimg"].src in immer gleicher Weise darauf zugreifen kann. Alles sehr fein, und ganz ohne eval(). ;-)Genaugenommen werden globale Variablen und Funktionen uebrigens einfach als Eigenschaften des window-Objekts abgelegt. Damit werden dann Konstruktionen wie parent.framename.funktion() moeglich (parent.framename ist ja auch ein window-Objekt). Somit wird also mit window genau das getan, was ich oben mit globals gemacht habe. Nur werden hier die neuen Variablen eben mit den Eigenschaften und Methoden von window durcheinandergewuerfelt, wobei man durchaus auch mal eine aus Versehen ueberschreiben kann, wenn man nicht aufpasst. (Und welche Eigenschaften schon existieren, ist browserabhaengig!) Und das ist meines Wissens nicht dokumentiert, was logisch scheint, da JS ja auch in Umgebungen eingesetzt werden kann, wo es kein window-Objekt gibt. Insofern kann man sich also auch nicht drauf verlassen, dass das ueberhaupt in allen Browsern so funktioniert.
Naja, ich hoffe, es war irgentwie interessant. :S
Ich auch. ;-) Wie gesagt, ich mag Thread-Drifts.
So long
P.S. So, jetzt aber raus in die Sonne.
-
Hi Calocybe,
von Dir kann man echt was lernen; gut, daß Du Dich so stark an diesem Thema beteiligst.
var globals = [ ]; /* <==> var globals = new Array(); */
dann kann man dynamisch mit
var tmp;
globals["menu_1"] = [ ];
tmp = globals["menu_1"]["mouseoverimg"] = new Image();
tmp.src = "/images/...gif";
usw. sehr schoen seine dynamischen Daten aufbauen. Dann kann man z.B. einen kompletten "Unterzweig" an eine Funktion uebergeben:
funktion(globals["menu_1"]);
die dann mit arg["mouseoverimg"].src in immer gleicher Weise darauf zugreifen kann. Alles sehr fein, und ganz ohne eval(). ;-)Also, das ist wirklich interessant. Klaro, Arrays, die noch keine festgelegte Länge haben...und dann auf die Eintrage mit Strings zugreifen. Nicht schlecht.
Genaugenommen werden globale Variablen und Funktionen uebrigens einfach als Eigenschaften des window-Objekts abgelegt. [..]
Nur werden hier die neuen Variablen eben mit den Eigenschaften und Methoden von window durcheinandergewuerfelt, wobei man durchaus auch mal eine aus Versehen ueberschreiben kann, wenn man nicht aufpasst.Vielleicht kann man das, auch wenn trotzdem bei der Deklaration ausnutzen und Abfragen ob's Probleme gibt mit if(window.variable) oder so. (Hmm...was wenn variable == 0?)
Also diese letzte Ideee ist tatsächlich irgentwie elegant genug, daß ich sie mal ausprobiere. Wenn das Script übersichtlier wird...dann nehme ich sie vielleicht.Es gibt übrigens noch andere Scripte, wo ich diese Methode brauchen könnte, oder eben auch die obere, die Du besser findest.
Da ich inzwischen eher geneigt bin alle Daten ein und desselben Objektes in einem Object zu kapseln (Größe, Position, Zustand), könnte ein geschickt formuliertes Object-Array, ähnlich dem globals-Array, in solchen Fällen im Script echt schick wirken:
fliegenArray = new Array(); fliegenArray["Fliege_1"] = new fliegenObject(... );
und später in einer Funktion:
function bewege(fliegenName)
{
with(fliegenArray[fliegenName])
{
...
}
}Hmm...das sieht schon gut aus...
Referenzieren über einen String erschien mir bisher immer albern...aber so fallen bei mir 'ne Menge evals weg, und der Code wird lesbarer. (Obwohl er gar nicht so unlesbar ist...)Still working...
Simy
PS: Das Fliegenmotiv kommt nicht von ungefähr...ich finde meine 10-20 Fliegen, die ganz unverhofft auf der Seite auftauchen, sehen schon echt klasse aus...
-
Hi again!
Vielleicht kann man das, auch wenn trotzdem bei der Deklaration ausnutzen und Abfragen ob's Probleme gibt mit if(window.variable) oder so. (Hmm...was wenn variable == 0?)
Mmh... das Thema hatten wir hier vor langer Zeit mal, sind's aber nicht bis zum Ende durchgegangen. Ich glaube, der korrekteste Weg ist wohl
if (typeof(window.variable) == "undefined") { /* alles klar */ }
oder so. Finde ich aber zu umstaendlich.Da ich inzwischen eher geneigt bin alle Daten ein und desselben Objektes in einem Object zu kapseln (Größe, Position, Zustand), könnte ein geschickt formuliertes Object-Array, ähnlich dem globals-Array, in solchen Fällen im Script echt schick wirken:
fliegenArray = new Array(); fliegenArray["Fliege_1"] = new fliegenObject(... );Auf jeden Fall!
Uebrigens sind Objekte und Arrays in Wirklichkeit dasselbe in JS. Such mal im 99er Archiv nach "Kontinuum".und später in einer Funktion:
function bewege(fliegenName)
{
with(fliegenArray[fliegenName])
{
...
}
}Das schreit geradezu nach einem objektorientierten Ansatz. Schliesslich ist doch
fliegenArray[fliegenName].bewege();
viel cooler (und nebenbei sauberer, wiederverwendbarer, blahblahblah) als
bewege(fliegenName);
Man schreibt auch
zweitfenster.moveTo(x, y);
statt
MoveWindowTo(zweitfenster, x, y);
Aber naja, ich weiss nicht, wie weit Du schon bist, und man muss ja nicht alles an einem Tag lernen.PS: Das Fliegenmotiv kommt nicht von ungefähr...ich finde meine 10-20 Fliegen, die ganz unverhofft auf der Seite auftauchen, sehen schon echt klasse aus...
Man ist gespannt. ;-)
So long
-
Hallo Calocybe,
PS: Das Fliegenmotiv kommt nicht von ungefähr...ich finde meine 10-20 Fliegen, die ganz unverhofft auf der Seite auftauchen, sehen schon echt klasse aus...
Man ist gespannt. ;-)Tja...und ich stellte fest, daß ich das mit den Fliegen schon so gelöst hatte, ABER diese einfach zu verwendende Menu hatte das noch nicht!
Also habe ich mich rangemacht...und siehe da: das Script ist nur noch etwas über 2 Seitenlängen groß, und auch noch super erweiterbar für demnächst: DOM und Netscape 6.x .
Es hat also echt was gebracht und mit der Eleganz...ich muß schon sagen...sehr schön.Der Tip mit: Array = Object kommt gut an: jetzt heißt es statt:
eval("document."+ name +".visibility [...] ");
nur noch:
document.layers[name].visibility [...] ;
was ja wirklich besser ist, wenn man layer anspricht.
Ich habe nur kein Pendant zum all-Object gefunden, ein div-Tag mit Namen per String zu referenzieren.Außerdem suche ich seit geraumer Zeit nach Pointern auf Variablen...aber das scheint es gar nicht zu geben in JavaScript, oder nur auf Funktionen...
Wäre schon interesant...
Gruß, Simy
PS:Naja...eigentlich müsste man schon einen neuen Thread aufmachen für solche Themen...
-
Hi again!
Außerdem suche ich seit geraumer Zeit nach Pointern auf Variablen...aber das scheint es gar nicht zu geben in JavaScript, oder nur auf Funktionen...
Das gibt es leider so direkt nicht (bisher, hoffentlich aendert sich das in zukuenftigen Versionen), allerdings sind Objekte in Wirklichkeit Referenzen (Pointer) auf Objekte (und zwar immer). Wenn Du also
var x = new Date;
var y = x;
schreibst, hast Du in x und y zwei Referenzen auf *dasselbe* Date-Objekt. Dadurch wird es moeglich, z.B. ein bestimmtes Formularfeld (ist ja ein Objekt) an eine Funktion zu uebergeben und dann aus der Funktion heraus direkt auf dieses Formularfeld zuzugreifen, also insbesondere auch schreibend.Eine fiese Stelle ist jetzt noch, dass es sowohl die primitiven Datentypen Zahl, String und Boolean in JS gibt, aber auch zugehoerige kapselnde Objekte (Wrapper), naemlich Object Number, Object String und Object Boolean. Die primitiven Typen werden by value uebergeben, die Wrapper objects aber by reference. Auch ist die Abfrage
if (objekt)
immer true, auch wenn z.B. ein Boolean-Objekt den Wert false enthaelt (siehe Beschreibung des Objekts in der Ref).So long
-
-
-
-
-
-
Hi,
Naja, wuerde JS sich einfach verhalten wie eine vernuenftige Sprache und immer auf der ordentlichen Deklaration von Variablen bestehen, haetten wir das Problem nicht.
Mich juckt es nicht in geringster Weise das JS die Deklaration einer Variable zwingend vorschreibt. Es gehoert einfach zu einem guten Programmierstiel das man dies tut, egal ob es die Sprache verlangt oder nicht.
(Aehnliches gilt fuer die hirnverbrannte automatische Typenumwandlung.)
Genau wie oben, es wird niemand gezwungen DAMIT oder SO zu arbeiten, also immer schoen String und parseInt benutzen.
Es ist nun mal leider so, das die Leute sich zu erst mit der Syntax und Eigenarten einer Sprache auseinandersetzen. Wenn dann etwas nicht funzt sind sie Ratlos weil sie in ihren Deklarationsfehlern, Variablentypen und Wuselcode nicht mehr Durchblicken. Dabei kann man mit einen guten Progstiel 50% aller Fehler erst gar nicht entstehen lassen und die Bugsuche geht auch um einiges schneller. Ich musste diesen Lernprozess auch sehr schmerzlich durchmachen. Das liegt aber hauptsaechlich daran das darauf viel zu wenig (oder nicht energisch genug) hingewiesen wird (auch bei Selfhtml).
viele Gruesse
Thomas Mell-
Moin Thomas!
Genau wie oben, es wird niemand gezwungen DAMIT oder SO zu arbeiten, also immer schoen String und parseInt benutzen.
Hier ist das Problem, man muss aber trotzdem erst um diese Eigenheiten wissen. Nicht umsonst gibt es hier ja aller zwei Tage die Frage, warum "1" + "1" == "11" ist und nicht 2. Na gut, man kann argumentieren, man muss schliesslich eine Sprache kennen, bevor man mit ihr arbeiten kann. Aber gerade bei einer einfach gehaltenen Scriptsprache ist es doch eher kontraproduktiv, dass einem einerseits die Existenz der Typisierung vorenthalten wird, andererseits muss man aber genau wissen, dass sie existiert und an welchen Stellen automatisch konvertiert wird, um sich nicht staendig ueber die Ergebnisse zu wundern. (Z.B. auch warum steht nach <A href="javascript:window.open(...)" > ploetzlich [object window] im oeffnenden Fenster?)
Es ist nun mal leider so, das die Leute sich zu erst mit der Syntax und Eigenarten einer Sprache auseinandersetzen. Wenn dann etwas nicht funzt sind sie Ratlos weil sie in ihren Deklarationsfehlern, Variablentypen und Wuselcode nicht mehr Durchblicken. Dabei kann man mit einen guten Progstiel 50% aller Fehler erst gar nicht entstehen lassen und die Bugsuche geht auch um einiges schneller.
Da hast Du voellig recht. JavaScript richtet sich halt von seinem primaeren Einsatzfeld her eben auch in grossem Masze an Nichtprogrammierer, ja an Leute, die mit Programmierung eigentlich nichts zu tun haben wollen.
Ich musste diesen Lernprozess auch sehr schmerzlich durchmachen. Das liegt aber hauptsaechlich daran das darauf viel zu wenig (oder nicht energisch genug) hingewiesen wird (auch bei Selfhtml).
Auch Selfhtml richtet sich eben eher an Nichtprogrammierer (logisch).
So long
-
High
Da hast Du voellig recht. JavaScript richtet sich halt von seinem primaeren Einsatzfeld her eben auch in grossem Masze an Nichtprogrammierer, ja an Leute, die mit Programmierung eigentlich nichts zu tun haben wollen.
Ich bin absolut nicht der Meinung das Javascript sich an die Masse und/oder Nichtprogrammierer richtet. Schau dir nur mal die Doku von M$ an, DOM, XML, XSL, DHTML und alles mit Javascript an.
Aus den Kinderschuhen ist JS schon lange raus und eine richtige Programmiersprache geworden. Das Zusammenspiel der genannten Technologien ist um ein vielfaches komplizierter als die meissten Programmiersprachen.Auch Selfhtml richtet sich eben eher an Nichtprogrammierer (logisch).
Das rechtfertigt aber noch lange nicht gerade den Anfaengern einen schlechten Programmierstiel anzugewoehnen. Wenn der erst mal "drinn" ist, kann man ihn nur sehr schwer austreiben. Ausserdem sehe ich ueberhaupt kein Hinderniss einen Anfaenger wenigstens die groebsten Programmiergrundlagen zu vermitteln, es ist um einiges leichter als die Sprache selber, erspart aber sehr viel Aerger und Frusterlebnisse.
schoene Gruesse
Thomas-
Re-Hi!
Ich bin absolut nicht der Meinung das Javascript sich an die Masse und/oder Nichtprogrammierer richtet. Schau dir nur mal die Doku von M$ an, DOM, XML, XSL, DHTML und alles mit Javascript an.
Na gut, das ist wahr, aber das sind alles nur Anwendungen. Die Sprache an sich ist leider ziemlich primitiv, weil es urspruenglich nunmal so gedacht war. Aber wie ich mal auf mozilla.org im Vorbeigehen gesehen habe, koennte sich das mit JS2.0 drastisch aendern. Auch bezueglich der ECMA-Spec bin ich nicht auf dem aktuellen Stand, vielleicht hat sich dort auch schon einiges getan.
Aus den Kinderschuhen ist JS schon lange raus und eine richtige Programmiersprache geworden. Das Zusammenspiel der genannten Technologien ist um ein vielfaches komplizierter als die meissten Programmiersprachen.
Das sind quasi Bibliotheken, da kann ich z.B. fuer Perl noch 100 mal soviel finden.
Das rechtfertigt aber noch lange nicht gerade den Anfaengern einen schlechten Programmierstiel anzugewoehnen. Wenn der erst mal "drinn" ist, kann man ihn nur sehr schwer austreiben. Ausserdem sehe ich ueberhaupt kein Hinderniss einen Anfaenger wenigstens die groebsten Programmiergrundlagen zu vermitteln, es ist um einiges leichter als die Sprache selber, erspart aber sehr viel Aerger und Frusterlebnisse.
Ich sehe da aber eines: Man kann nur weitergeben, was man selber weiss.
So long
-
-
-
-
Hi auch,
Naja, wuerde JS sich einfach verhalten wie eine vernuenftige Sprache und immer auf der ordentlichen Deklaration von Variablen bestehen, haetten wir das Problem nicht. (Aehnliches gilt fuer die hirnverbrannte automatische Typenumwandlung.)
locker bleiben :-) zumal das Verhalten von JS ja wohl eindeutig genug
ist um sicher damit arbeiten zu können. Im Vergleich zu einigen
Scriptsprachen/Programmiersprachen für Datenbanken finde ich den Umgang
mit Variablen bei JS direkt erholsam und erfreulich kompakt.
Ich vermute daß sich Deine Ansprüche an eine "vernuenftige Sprache"
eher aus dem Vergleich mit anderen Sprachen und Deinen Gewohnheiten als
aus der Vernunft ergeben.
Das wäre dann ähnlich wenn ich fordern würde in der Leiste oben vom
Posting neben SELFHTML Forum den Punkt SELFHTML Help zu finden, weil
ich das in eingen WinxProgrammen so gewohnt bin.Grüsse
Cyx23
-
Moin!
locker bleiben :-) zumal das Verhalten von JS ja wohl eindeutig genug
ist um sicher damit arbeiten zu können.Wenn man es *kennt*, dann ja. Doch wieviele Anfaenger kennen die Sprache ueberhaupt?
Im Vergleich zu einigen
Scriptsprachen/Programmiersprachen für Datenbanken finde ich den Umgang
mit Variablen bei JS direkt erholsam und erfreulich kompakt.Es gibt sicher immer irgendwas, was noch schlimmer ist. ;-)
Ich vermute daß sich Deine Ansprüche an eine "vernuenftige Sprache"
eher aus dem Vergleich mit anderen Sprachen und Deinen Gewohnheiten als
aus der Vernunft ergeben.Da muss ich widersprechen. Ich habe durchaus schon mit einer gewissen Anzahl verschiedener Sprachen programmiert und bilde mir ein, zu wissen, wo Vor- und Nachteile von AutoMagics liegen. (Z.B. Perl strotzt ja noch viel mehr davon, was auch nicht gerade zur Vereinfachung der Fehlersuche beitraegt.)
Das wäre dann ähnlich wenn ich fordern würde in der Leiste oben vom
Posting neben SELFHTML Forum den Punkt SELFHTML Help zu finden, weil
ich das in eingen WinxProgrammen so gewohnt bin.Noe. Aber wenn Du (aus Sicht des Kommunikationsdesigns (nebenbei: gute Seite dazu: http://www.kommdesign.de/)) gut begruenden kannst, warum da so ein Menuepunkt hingehoert, dann ist das vergleichbar.
So long
-
-
-
-
-