nicht angemeldet molily
molily
molily
molily
molily
molily
molily
Hi,
ich hätte mal eine Frage zu JavaScript und this.
Ich habe eine "Klasse", die meinetwegen so aussieht:
var MyClass = function()
{
};
MyClass.prototype =
{
methode1: function()
{
this.methode2();
},
methode2: function()
{
}
};
var obj = new MyClass();
obj.methode1();
das geht ja noch soweit.
Jetzt möchte ich aber methode1 als event handler für ein eigenes event nutzen.
Dazu übergebe ich die methode, also obj.methode1 an eine Funktion, die meine Events handelt, und rufe sie darin auf:
raiseMyEvent: function(handler)
{
handler(); // handler ist z.B. obj.methode1
}
Problem ist nun, dass this in methode1 nicht mehr auf obj zeigt, sondern irgendwo anders hin.
Kriegt man diese Problem gelöst?
Ähnliches ist, wenn ich schreibe:
var test = obj.methode1;
test();
dann ist this auch anders. Letzteres Problem kriegt man ja noch mit apply in den Griff: var test = obj.methode1.apply(obj);
aber das ist ja irgendwie blöd, und für erstes problem auch nicht mehr machbar.
Gruß!
Hallo,
Jetzt möchte ich aber methode1 als event handler für ein eigenes event nutzen.
Problem ist nun, dass this in methode1 nicht mehr auf obj zeigt, sondern irgendwo anders hin.
Nicht "irgendwo anders hin", sondern bei Eventhandlern zeigt this immer auf das Objekt, das den Event auslöst:
element.onclick = obj.methode1; // "this" in Methode1 ist das element
Kriegt man diese Problem gelöst?
Wenn du von Methode1 aus immer auf Methode2 desselben Objekts zugreifen willst, kannst du z.B. der Methode das Objekt als Parameter mitgeben:
MyClass.prototype =
{
methode1: function(obj)
{
obj.methode2();
},
methode2: function()
{
}
};
var obj = new MyClass();
obj.methode1(obj);
Mir ist aber nicht ganz klar, was du eigentlich erreichen willst. Wozu brauchst du Klasse MyClass? Das macht nur Sinn, wenn du mehrere solche Objekte erzeugen willst. Und wozu genau dient die Funktion raiseMyEvent? Es ist anscheinend eine Methode irgend eines anderen Objekts. Das hast du aber nicht notiert. Was ist dass denn für ein Objekt und wie soll das dann konkret funktionieren?
Gruß, Don P
Hi,
var obj = new MyClass();
obj.methode1(obj);
ja, das ist ja unpraktikabel. ähnlich der obj.method1.apply(obj)
Mir ist aber nicht ganz klar, was du eigentlich erreichen willst. Wozu brauchst du Klasse MyClass? Das macht nur Sinn, wenn du mehrere solche Objekte erzeugen willst. Und wozu genau dient die Funktion raiseMyEvent? Es ist anscheinend eine Methode irgend eines anderen Objekts. Das hast du aber nicht notiert. Was ist dass denn für ein Objekt und wie soll das dann konkret funktionieren?
Die raiseEvent Methode ist eine Methode eines anderen Objekts, richtig. Diente ja auch nur als Beispiel.
Problem ist dieses:
Ich habe eine "Klasse" mit Methoden, von der ich ein Objekt erzeuge. Ich könnte dieses Objekt auch direkt so erzeugen:
var myObj =
{
methode1: function()
{
this.methode2();
},
methode2: function()
{
}
};
wenn ich nun obj.methode1() aufrufe, klappt alles. Also es wird die methode2 aufgerufen.
wenn ich aber schreibe:
var handler = obj.methode1;
hander();
dann zeigt this irgendwo anders hin (glaub auf das window objekt) und es kracht. Ich würde an dieser Stelle erwarten, dass alles noch genauso funktioniert.
Nun hab ich ein z.B. eine Klasse welche das Verhalten von einer Tabelle steuert. Dort hab ich einen Event, der feuern soll, wenn man eine Tabellenzelle hinzufügt:
[...]
addCell: function()
{
this.table.insertCell(-1);
this.raiseCellAdded();
},
raiseCellAdded: function()
{
this.cellAddedHandler();
}
[...]
var myTable = new MyTable();
myTable.cellAddedHandler = obj.methode1;
myTable.addCell();
das this in obj.methode1 zeigt nun auf myTable anstatt auf obj1.
Naja, nur so als Beispiel.
Problem ist dass man nie weiß in welchem Kontext cellAddedHandler aufgerufen werden muss. Man weiß nur dass es vom Typ "function" ist... Oder gibts Möglichkeit das Original Objekt, zu dem eine Methode gehört, herauszufinden?
Gruß!
Hallo,
Ich habe eine "Klasse" mit Methoden, von der ich ein Objekt erzeuge. Ich könnte dieses Objekt auch direkt so erzeugen:
var myObj =
{
methode1: function()
{
this.methode2();
},
methode2: function()
{
}
};
Genau, eine "Klasse" brauchst du nicht, wenn du nicht mehrere solche Objekte mit erzeugen willst.
wenn ich aber schreibe:
var handler = obj.methode1;
hander();dann zeigt this irgendwo anders hin (glaub auf das window objekt) und es kracht.
Ja, in diesem Fall kannst du "this" in methode1 nicht wie gewünscht verwenden. Das ist aber auch nicht nötig. Da du nur ein einziges solches Objekt hast und auch weißt, wie es heißt, kannst du den Namen direkt notieren:
var myObj = {
methode1: function()
{
myObj.methode2();
},
methode2: function()
{
}
};
Oder gibts Möglichkeit das Original Objekt, zu dem eine Methode gehört, herauszufinden?
Nicht direkt. Wie LanX bereits schrieb, geht das aber z.B. über eine Variable, die beim Initialisieren des Objekts gesetzt wird, z.B. so:
var myObj = {
init: function ()
{
this.methode1.self = this;
},
methode1: function()
{
arguments.callee.self.methode2(); // arguments.callee ist methode1
},
methode2: function()
{
}
};
myObj.init() // Das Objekt einmalig initialisieren.
var handler = myObj.methode1;
handler();
Oder, wenn's etwas raffinierter sein darf:
var myObj = ({
init: function ()
{
this.methode1.self = this;
return this;
},
methode1: function()
{
arguments.callee.self.methode2();
},
methode2: function()
{
}
}).init(); // Das Objekt sofort initialisieren.
var handler = myObj.methode1;
handler();
Gruß, Don P
Hi,
Ja, in diesem Fall kannst du "this" in methode1 nicht wie gewünscht verwenden. Das ist aber auch nicht nötig. Da du nur ein einziges solches Objekt hast und auch weißt, wie es heißt, kannst du den Namen direkt notieren:
var myObj = {
methode1: function()
{
myObj.methode2();
},
methode2: function()
{
}
};
Ganz so einfach ist es leider nicht. Ich habe schon eine Klasse, und die Methoden stecken im prototype. Habe es hier der Einfachheithalber nur weggelassen.
> > Oder gibts Möglichkeit das Original Objekt, zu dem eine Methode gehört, herauszufinden?
>
> Nicht direkt. Wie LanX bereits schrieb, geht das aber z.B. über eine Variable, die beim Initialisieren des Objekts gesetzt wird, z.B. so:
>
> [code lang=javascript]
> var myObj = {
>
> init: function ()
> {
> this.methode1.self = this;
> },
>
> methode1: function()
> {
> arguments.callee.self.methode2(); // arguments.callee ist methode1
> },
> methode2: function()
> {
> }
> };
Hm, sehr unschön. Wir arbeiten in einem größeren Team, und es ist nicht möglich, so was durchzusetzen. Außerdem müsste man jede Methode damit ausstatten, und sowas hat man ja schnell mal übersehen.
Gruß!
Hallo,
Ganz so einfach ist es leider nicht. Ich habe schon eine Klasse, und die Methoden stecken im prototype.
Ok, aber warum? Klassen und prototypische Vererbung benutzt man doch nur, wenn mehrere Objekte davon erzeugen will. Ist das denn überhaupt der Fall oder willst du die Frage möglichst allgemein lösen?
Wenn es denn unbedingt so sein muss, kannst du mit einer normalen Closure-Variable arbeiten:
var MyClass = function () {};
MyClass.prototype = new (function () {
var self = this;
this.methode1 = function() {
self.methode2();
};
this.methode2 = function() {
};
});
var obj = new MyClass();
var handler = obj.methode1;
handler();
Gruß, Don P
Hallo Christian
Also entweder ich verstehe nicht dein problem oder du verstehst nicht meinen Vorschlag...
Konkret (ungetestet):
function myConst {
self=this;
self.attr1="...";
self.methode1= function () { alert (self.attr1) };
}
myObj=new myConst();
Die Variable self ist in der Hülle (closure) von methode1 deklariert und konserviert deswegen die Referenz zu diesem (this) Objekt zum Zeitpunkt der Konstruktion, egal wo später Methode1 aufgerufen wird, also auch von einem eventhandler aus.
"this" ändert sich aber - wie du richtig beobachtest, in Abhängigkeit zur Aufrufart.
Alles klar?!? (oder willst du was ganz anderes???)
So long
LanX
Hallo,
function myConst {
self=this;
Wah!
Waah!
Waaaah!
var!
;)
Das globale Objekt self will man nicht wirklich überschreiben... ;)
(Ist auch eigentlich als »eingeschlossene« Variable kein so sinnvoller Name, auch wenn ich das selbst so mache. Eigentlich braucht man self, also die Referenz auf window, nie wirklich, aber es ist zumindest verwirrend.)
Mathias
Kurtz gegrüßt
Das globale Objekt self will man nicht wirklich überschreiben... ;)
Hmm ist wohl nur eine globale Variable die === window ist.
Ändern von self in FF tangiert aber nicht window.
Aber wozu? Für JS-Umgebungen wo es kein Window gibt, wie WSH?
LanX's Code hatte übrigens noch mehr Flüchtigkeitsfehler ... "ungetestet" halt.
(Ist auch eigentlich als »eingeschlossene« Variable kein so sinnvoller Name, auch wenn ich das selbst so mache.
naja Perl lässt grüßen!
Wie wärs mit "home"? Drückt aus das es sich um die "Heimat" der Methode handeln soll.
Andere Vorschläge?
Eigentlich braucht man self, also die Referenz auf window, nie wirklich, aber es ist zumindest verwirrend.)
z.B. WSH oder Spidermonkey??? s.o.
Grüße
Kurt
Hallo KurtZ,
Wie wärs mit "home"? Drückt aus das es sich um die "Heimat" der Methode handeln soll.
Andere Vorschläge?
thiss, myself, selfObj, ownObject, parentObj...
Ich nehme immer "that" (nur in diesem thread nicht, weil "self" bereits vorgeschlagen war und ich keine unnötige Verwirrung stiften wollte).
Eigentlich braucht man self, also die Referenz auf window, nie wirklich, aber es ist zumindest verwirrend.)
Ja, self benutze ich auch nie. Ergibt self === window eigentlich *immer* true?
Gruß, Don P
Grüße
Andere Vorschläge?
thiss, myself, selfObj,
man sollte sich namentlich von this und self abheben um Missverständnisse zu vermeiden.
ownObject, parentObj...
Viel besser, parent würd ich aber für DOM-Node-Hierachien reservieren.
Wie wärs mit "owner"? korrespondiert gut mit hasOwnProperty und macht deutlich dass es nur *einen* owner geben sollte.
"home" war auch nicht schlecht, aber dann favorisiere ich "host". Der Gastgeber ist eine Person, die Heimat nur ein Ort. Auch kann man in RL auch Ketten von Gastgebern haben.
Ich nehme immer "that" (nur in diesem thread nicht, weil "self" bereits vorgeschlagen war und ich keine unnötige Verwirrung stiften wollte).
naja that ist von der Bedeutung nur eine sprachliche Variation von this, hier gehts aber um eine konkrete Verschärfung von this.
Eigentlich braucht man self, also die Referenz auf window, nie wirklich, aber es ist zumindest verwirrend.)
Ja, self benutze ich auch nie. Ergibt self === window eigentlich *immer* true?
IMHO in Browsern ja, auch in frames. aber wie KurtZ richtig bemerkte gibts ja JS nicht nur in Browsern. Und da *könnte* es immernoch "self" geben, aber das globale Objekt hieße dann nicht "window".
M.a.W. self *könnte* also JS-Core sein, window aber BOM. (*konjunktiv*, ich habs nicht nachgeprüft)
So long
LanX
Hallo,
thiss, myself, selfObj,
man sollte sich namentlich von this und self abheben um Missverständnisse zu vermeiden.
Hmm, "thiss" würde vielleicht für manche wie ein typo aussehen und beim debugging dann verschlimmbessert werden...
parent würd ich aber für DOM-Node-Hierachien reservieren.
Stimmt, das macht mehr Sinn.
Wie wärs mit "owner"? korrespondiert gut mit hasOwnProperty und macht deutlich dass es nur *einen* owner geben sollte.
Oder einfach nur "own"! Das ist knapp und verständlich. Alternativ vielleicht my oder our, klingt aber zu sehr nach Perl und sieht gegen "own" richtig old aus.
"home" war auch nicht schlecht, aber dann favorisiere ich "host". Der Gastgeber ist eine Person, die Heimat nur ein Ort. Auch kann man in RL auch Ketten von Gastgebern haben.
"host" assoziiert man doch meistens mit einem ganzen Rechner. Scheint mir zu mächtig für so eine kleine Sache.
naja that ist von der Bedeutung nur eine sprachliche Variation von this
Gemeint ist ja auch eine Art "this", nur dass jenes eben ein bisschen unzuverlässig ist.
M.a.W. self *könnte* also JS-Core sein, window aber BOM. (*konjunktiv*, ich habs nicht nachgeprüft)
Wie auch immer, da "self" nunmal bereits vergeben ist, wenn auch vielleicht nicht überall, sollte man es einfach in Ruhe lassen. Es geibt ja genügend andere Buchstabenkombinationen :-)
Ich werde wohl in Zukunft "own" verwenden.
Gruß, Don P
Hi
Ich werde wohl in Zukunft "own" verwenden.
gramatikalisch wär owner IMHO besser, das ist der Unterschied zw. Subjekt und Objekt, und kommt hasOwnProperty nicht in die Quere.
Wenn du aber meinst was deinem Besitzer ist, ist geichzeitig auch dir soltest du "our" nehmen, allerdings gefällt mir nicht die verwirrung mit Perl. Dort würde "our" globale Packagevariablen bezeichnen.
Ich bleib erstmal bei "owner", die begriffliche Klarstellung ist mir 2 Tasten mehr Wert. Und dass das kein Core-JS Bezeichner ist [1], rechtfertigt die visuelle Hervorhebung.
Passt auch sprachlich gut zu anderen Begriffen wie "open" und "opener".
So long
LanX
[1] eine Funktion kann halt normalerweise Methode beliebig vieler Objekte sein.
Hallo,
gramatikalisch wär owner IMHO besser, das ist der Unterschied zw. Subjekt und Objekt,
Gerade grammatikalisch finde ich "own" passender, weil es als Possessivpronomen ein Besitzverhältnis anzeigt und sich somit wie natürliche Sprache liest:
own.god = 'M$';
return own.prayer(own.god);
und kommt hasOwnProperty nicht in die Quere.
"own" aber doch auch nicht. Im Gegenteil, dass beide mit demselben Thema zu tun haben, wird durch "own" richtig deutlich. Wo siehst du da ein Problem?
Wenn du aber meinst was deinem Besitzer ist, ist geichzeitig auch dir soltest du "our" nehmen, allerdings gefällt mir nicht die verwirrung mit Perl.
Genau, letzteres stört mich auch.
Gruß, Don P
Hallo
und kommt hasOwnProperty nicht in die Quere.
"own" aber doch auch nicht. Im Gegenteil, dass beide mit demselben Thema zu tun haben, wird durch "own" richtig deutlich. Wo siehst du da ein Problem?
wie gesagt, soviel gemeinsam wie Subjekt und Objekt:
bei bund.bahn.gleis gilt "bund" ist der owner vom owner von "gleis" ...
während "gleis" ein ownProperty von "bahn" wäre udn nicht umgekehrt.
aber mach wie du meinst...
so long
LanX
Grüße
IMHO in Browsern ja, auch in frames. aber wie KurtZ richtig bemerkte gibts ja JS nicht nur in Browsern. Und da *könnte* es immernoch "self" geben, aber das globale Objekt hieße dann nicht "window".
M.a.W. self *könnte* also JS-Core sein, window aber BOM. (*konjunktiv*, ich habs nicht nachgeprüft)
hmm in der ecma3 spezifikation war "self" gar nicht zu finden, und die variable "window" wird als browserspezifischer non-standard bezeichnet.
Auch zählen einige Quellen das window-objekt zum DOM andere zum BOM.
hmm ?!?
So long
LanX
Hallo,
Auch zählen einige Quellen das window-objekt zum DOM andere zum BOM.
Also DOM ist es jedenfalls nicht, BOM ist genau dafür der richtige Begriff. Wobei es eher eine Analogiebildung zu DOM ist, keine Spezifikation verwendet diesen Begriff, ganz im Gegensatz zum (W3C) DOM.
Mathias
Hallo
Also DOM ist es jedenfalls nicht, BOM ist genau dafür der richtige Begriff. Wobei es eher eine Analogiebildung zu DOM ist, keine Spezifikation verwendet diesen Begriff, ganz im Gegensatz zum (W3C) DOM.
http://www.oreilly.de/catalog/learningjvscptger/ nutzt den Begriff "BOM" und zählt Window dazu.
Im MDC wird window als DOM-Object aufgeführt.http://www.oreilly.de/catalog/learningjvscptger/
in der ECMA-Spezi wird auch die globale variable window erwähnt.
Ist ein Grenzfall... einerseits erweitert die Frames-Hierarchie IMHO den Dokumentbaum auf natürliche Weise, andererseits gibts in Window properties die IMHO zu browserspezifisch sind, um DOM zu sein.
Hmm, ich denke es ist BOM.
so long
LanX
Hallo
Im MDC wird window als DOM-Object aufgeführt.http://www.oreilly.de/catalog/learningjvscptger/
c&p fehler http://developer.mozilla.org/en/docs/DOM:window
so long
LanX
Hallo,
Hmm, ich denke es ist BOM.
Falls der Begriff nicht schon irgendwie existierte, müsste man ihn erfinden :-).
Es gibt nämlich mehrere DOMs, je nach Host-Anwendung. Die ECMA-Spezifikation spricht meines Wissens nur vom "global Object", im Browser heißt das bekanntlich "window", bei Adobe z.B. "app". Eigentlich hat es keinen Namen (wieso erinnert mich das an Mose?). Jedenfalls hängt das ganze DOM, in welcher Host-Anwendung auch immer, am namenlosen globalen Objekt.
Es ist m.E. schon sinnvoll, das Browser-DOM einfach als BOM zu bezeichen, und "window" gehört dann zweifellos zum BOM.
Gruß, Don P
Hi
Es ist m.E. schon sinnvoll, das Browser-DOM einfach als BOM zu bezeichen, und "window" gehört dann zweifellos zum BOM.
missverständnis BOM soll (zumindest nach Shelley Powers) alles umfassen was nicht ECMA oder DOM ist.
DOM ist für mich (grob gesprochen) alles was mit getElementById abgerufen werden kann, das Dokument halt.
Framesets sind ein Grenzfall ... da bin ich im zwiespalt.
grüße
LanX
Hallo,
Es ist m.E. schon sinnvoll, das Browser-DOM einfach als BOM zu bezeichen, und "window" gehört dann zweifellos zum BOM.
missverständnis BOM soll (zumindest nach Shelley Powers) alles umfassen was nicht ECMA oder DOM ist.
DOM ist für mich (grob gesprochen) alles was mit getElementById abgerufen werden kann, das Dokument halt.
Ach so. Aber was soll dann das "B" in BOM bedeuten? Doch wohl "Browser", oder? Wenn man es so auffasst, dass das DOM erst ab der document-Ebene beginnt, ist das das genannte BOM einfach ein spezielles HOM ("Host Object Model", meine Wortschöpfung jetzt).
Framesets sind ein Grenzfall ... da bin ich im zwiespalt.
In diesem Fall sind Framesets aber ganz klar "HOM" bzw. BOM: Ein Frame verhält sich gewissermaßen wie eigenes window. Dokumente gibt es erst unterhalb.
Ich sehe hier aber gar keine Notwendigkeit, DOM von einem "HOM" getrennt zu betrachten. Jede Host-Anwendung verarbeitet doch nur eine Art Dokumente, ein Bowser HTML-Dokumente, eine Grafikanwendung Bild-Dokumente usw. Jede Host-Anwendung hat also ohnehin ihr spezielles DOM, so dass man das DOM eines Browsers einfach BOM nennen kann, was dann das globale Objekt und Framesets mit einschließt.
Gruß, Don P
This category lists all "DOM Level 0" APIs. The term "DOM Level 0" refers to a mix (not formally specified) of HTML document functionalities offered by Netscape Navigator version 3.0 and Microsoft Internet Explorer version 3.0 or, sometimes, to a set of APIs which are not a part of any W3C DOM specification, but are implemented across several browsers.
http://developer.mozilla.org/en/docs/Category:DOM_0
m.a.W. Quasi-Standard
Hallo,
The term "DOM Level 0" refers to a mix (not formally specified) of HTML document functionalities offered by Netscape Navigator version 3.0 and Microsoft Internet Explorer version 3.0 or, sometimes, to a set of APIs which are not a part of any W3C DOM specification, but are implemented across several browsers.
Der Satz stammt teilweise aus dem Glossar der W3C-DOM-HTML-Spezifikation.
DOM Level 0 sind aus Sicht von W3C-DOM die proprietären Objektmodelle zum Zugriff auf das Dokument, als da wären document.all, document.layers und die noch älteren Kollektionen document.anchors/forms/images/links samt Konstruktoren/Objekttypen Form, Location, Option, Image usw.
http://aktuell.de.selfhtml.org/weblog/javascript-standards
Die Einordnung, die Mozilla da macht, ist Käse. window ist nicht DOM Level 0, weil es nichts mit Document zu tun hat, nicht - wie andere Teile von DOM Level 0 - in das DOM eingeflossen ist, geschweige denn überhaupt in dessen »Kompetenzbereich« fällt. Es kann per definitionem kein DOM geben, das window spezifiziert.
Mathias
Hallo
Die Einordnung, die Mozilla da macht, ist Käse. window ist nicht DOM Level 0, weil es nichts mit Document zu tun hat, nicht - wie andere Teile von DOM Level 0 - in das DOM eingeflossen ist, geschweige denn überhaupt in dessen »Kompetenzbereich« fällt. Es kann per definitionem kein DOM geben, das window spezifiziert.
Definition ist das entscheidende Wort. Begreift man Dokument als alles was unter dem Object "Document" hängt, ist dein Ansatz logisch.
Begreift man Dokument als eine Datei die die Endung .html trägt, haben die Netscapejünger recht.
Wahrscheinlich ist diese Paradoxie dem Browserkrieg geschuldet, Netscape als Urheber des DHTML (mit seinen Mozillanachfolgern) nimmt für sich in Anspruch "Dokument" damals(Level 0!) weiter auffassen zu dürfen, die DOM-Spezifikation hingegen war ein politischer Akt.
Anders gefragt: Wieso sollen frames anders behandelt werden als iframes (DOM-Level-2)? Und ein Frameset ist nicht DOM, kann aber ein ein <head> inklusive <title> haben und document.title wiederum ist DOM!
Hä ?!?
Wie auch immer, es ist müsig bei historische (Fehl-)Entwicklungen mit "Logik" zu argumentieren. Logisch wäre es gewesen eine stimmigeren Namen für das Objekt Document zu finden oder ein geschlossenes Design vorzulegen das Verwirrungen ausschließt.
Standards wachsen aber organisch und oft nicht logisch, weil konzeptionelle Logik zu teuer und aufwändig ist, um mit der normativen Kraft des Faktischen (marktbeherrschende Browser) konkurieren zu können.
"DOM-Level-0" ist IMHO zwar vertretbar, aber zu verwirrend, weswegen die Bezeichnung BOM in dieser Grauzone der "Quasistandards" vorzuziehen ist.
Das ist eine linguistische und keine logische Lösung, die (zumindest vorerst) historische Fußnoten braucht.
Cheers
LanX
Hallo,
Netscape als Urheber des DHTML (mit seinen Mozillanachfolgern) nimmt für sich in Anspruch "Dokument" damals(Level 0!) weiter auffassen zu dürfen
Wo tun sie das?
Anders gefragt: Wieso sollen frames anders behandelt werden als iframes (DOM-Level-2)?
Werden sie das?
Und ein Frameset ist nicht DOM, kann aber ein ein <head> inklusive <title> haben und document.title wiederum ist DOM!
DOM sieht Frames und Inner Frames als das, was sie auf Dokumentebene sind, bloße Elementknoten. Dann gibt es Brücken zwischen Dokumenten wie contentDocument.
Wie auch immer, es ist müsig bei historische (Fehl-)Entwicklungen mit "Logik" zu argumentieren. Logisch wäre es gewesen eine stimmigeren Namen für das Objekt Document zu finden oder ein geschlossenes Design vorzulegen das Verwirrungen ausschließt.
Ich sehe eigentlich keine Verwirrungen. Was ist die Fehlentwicklung? Dass das W3C erst in den letzten Jahren auf die Idee gekommen ist, auch Window zu standardisieren?
"DOM-Level-0" ist IMHO zwar vertretbar, aber zu verwirrend, weswegen die Bezeichnung BOM in dieser Grauzone der "Quasistandards" vorzuziehen ist.
Es sind Begriffe mit unterschiedlicher Funktion für zwei unterschiedliche Sachgebiete.
Mathias
Hi
Und ein Frameset ist nicht DOM, kann aber ein ein <head> inklusive <title> haben und document.title wiederum ist DOM!
DOM sieht Frames und Inner Frames als das, was sie auf Dokumentebene sind, bloße Elementknoten. Dann gibt es Brücken zwischen Dokumenten wie contentDocument.
ehm ... , also für mich hieß DOM immer auch DOM-Tree, dass hieße ich müsste ein Frame auch über die Kindbeziehung erreichen können, vielleicht stelle ich mich ja ungeschickt an, kannst du mir die Koordinaten geben um zum "Elementknoten" Frameset zu gelangen?
<html>
<head>
<title>frameset</title>
<script>alert(document.childNodes[0].childNodes[1])</script>
</head>
<frameset cols="50%,*">
<frame name="links" src="links.html" id="b">
<frame name="rechts" src="rechts.html" scrolling="no">
</frameset>
</html>
hier erhalte ich aber "undefined". OK ich weiß dass getElementById('b') ginge, aber ich will auch über ein Array wie bei windows.frames darauf zugreifen können, ganz ohne id.
Habe jetzt eine *unmenge* an Zeit [1] gegoogelt um entsprechende DOM-Spezifikationen zu finden, habe aber immer nur Gecko-Quellen gefunden.
Für mich sieht das so aus als ob frame/frameset eben nicht im DOM-Tree hängt, sondern nur getElementById entsprechend gehackt wurde.
So long
LanX
[1] die ich eigentlich nicht habe.
nun...
... wenn man die Ausführung des Scriptes verzögert klappts! (Das Beispiel
in http://de.selfhtml.org/javascript/objekte/htmlelemente.htm#frameset hat mich auf eine zu optimistische Fährte geführt).
OK ich geb mich geschlagen, man braucht window.frames nicht um auf frames zuzugreifen!
was DOM-Level-0 anbelangt:
DOM Level 0
The term "DOM Level 0" refers to a mix (not formally specified) of HTML document functionalities offered by Netscape Navigator version 3.0 and Microsoft Internet Explorer version 3.0. In some cases, attributes or methods have been included for reasons of backward compatibility with "DOM Level 0".
http://www.w3.org/TR/2000/WD-DOM-Level-1-20000929/glossary.html
damals gabs halt nur window.frames
Cheers
LanX
Hi
Ich sehe eigentlich keine Verwirrungen. Was ist die Fehlentwicklung? Dass das W3C erst in den letzten Jahren auf die Idee gekommen ist, auch Window zu standardisieren?
Wenn Frames voll zum DOM gehören, wie kann ich dann DOM-Compliant auf den parent zugreifen?
Tschau
LanX
Hallo,
Es ist m.E. schon sinnvoll, das Browser-DOM einfach als BOM zu bezeichen, und "window" gehört dann zweifellos zum BOM.
Häh? »Browser-DOM« ist Unsinn, weil DOM von *Document* kommt. Der Browser ist kein Document, sondern enthält eines.
Mathias
Hallo,
Häh? »Browser-DOM« ist Unsinn, weil DOM von *Document* kommt.
Naja, eigentlich meinte ich HTML + ECMAscript, also »JavaScript« bzw. das, was ECMAscript von HTML weiß. Bin wohl noch immer am teilweise unbewussten Versuch, den Begriff JavaScript auch für andere Host-Anwendungen zu retten...
Der Browser ist kein Document, sondern enthält eines.
Sagen wir, der Browser kann solche lesen und anzeigen.
Bis dato scheint er einzig und allein für eine bestimmte Art *Document* (HTML) ausgelegt, also könnte man doch das zugrunde liegende HTML + ECMAscript kurz BOM nennen und konsequenterweise frameset und window dazu zählen. Anscheinend habt ihr da aber noch eine feinere Unterteilung.
Gruß, Don P
Sagen wir, der Browser kann solche lesen und anzeigen.
Bis dato scheint er einzig und allein für eine bestimmte Art *Document* (HTML) ausgelegt, also könnte man doch das zugrunde liegende HTML + ECMAscript kurz BOM nennen und konsequenterweise frameset und window dazu zählen. Anscheinend habt ihr da aber noch eine feinere Unterteilung.
Wir reden aneinander vorbei. HTML und ECMAScript sind nicht das BOM und window gehört nicht konsequenterweise dazu, sondern essentiell.
BOM bezeichnet das OBJEKTMODELL, das den Browser bzw. die Browserumgebung widerspiegelt - genauso wie das W3C-DOM das HTML-Dokument in Form von Objekten zugänglich macht.
Das sind die Objekte window und dessen Member sowie window.frames, window.location, window.history, window.navigator, window.screen usw.
Nichts anderes kann BOM ausdrücken, wenn es eine sinnvolle Analogiebildung zu DOM sein soll.
Noch einmal: Das Document Object Model ist der technische Standard, der die Repräsentation eines Dokuments in Form von Objekten beschreibt (genauer gesagt »Interfaces«, Schnittstellen zum Dokument bzw. seinen Teilen). Das grundlegende Konzept ist da ein »Knoten« sowie dessen Organisation in einer Baumstruktur.
Das Browser Object Model ist eine Objekt-Repräsentation des User-Agents, der logisch sowie in der Objekthierarchie das DOM umgibt, der auf einer grafischen, fensterbasierten Oberfläche arbeitet und der gewisse Navigationsmöglichkeiten bietet. Das oberste Konzept ist da ein »Fenster«.
Mathias
Hallo,
BOM bezeichnet das OBJEKTMODELL, das den Browser bzw. die Browserumgebung widerspiegelt - genauso wie das W3C-DOM das HTML-Dokument in Form von Objekten zugänglich macht.
Das Browser Object Model ist eine Objekt-Repräsentation des User-Agents, der logisch sowie in der Objekthierarchie das DOM umgibt, der auf einer grafischen, fensterbasierten Oberfläche arbeitet und der gewisse Navigationsmöglichkeiten bietet. Das oberste Konzept ist da ein »Fenster«.
Ok, da reden wir nicht wirklich aneinander vorbei. So habe ich das auch verstanden. window, frameset usw. gehören also dazu, nur darum ging es mir, auch wenn meine Begründung wohl nicht so elegant war, wie deine hier.
Ich habe da einfach mal grob die Gleichung
BOM = W3C-DOM + Browserinterne JavaScript-Objekte/Methoden zum Zugriff darauf
gesetzt und das unglücklicherweise auch mal als "Browser-DOM" bezeichnet. Aber im Grunde meinen wir wohl das gleiche.
Gruß, Don P
Der Browser ist kein Document, sondern enthält eines.
Sagen wir, der Browser kann solche lesen und anzeigen.
Bis dato scheint er einzig und allein für eine bestimmte Art *Document* (HTML) ausgelegt
?? Zumindest DOM Core gilt genauso für XML und damit für XHTML, SVG, MathML, XSLT, wasweißich, kann man alles mit Browsern lesen und verarbeiten. Außerdem ist das BOM erstmal gegenüber den angezeigten Dokumenten relativ gleichgültig, prinzipiell könnten auch SVG-, Flash- und PDF-Dokumente mit eingebetteten Scripten drin auf dasselbe BOM zugreifen. (Ist bei SVG auch der Fall, andernfalls weiß ich es nicht.)
Mathias
Hallo,
Der Browser ist kein Document, sondern enthält eines.
Sagen wir, der Browser kann solche lesen und anzeigen.
Bis dato scheint er einzig und allein für eine bestimmte Art *Document* (HTML) ausgelegt
?? Zumindest DOM Core gilt genauso für XML und damit für XHTML, SVG, MathML, XSLT, wasweißich, kann man alles mit Browsern lesen und verarbeiten. Außerdem ist das BOM erstmal gegenüber den angezeigten Dokumenten relativ gleichgültig, prinzipiell könnten auch SVG-, Flash- und PDF-Dokumente mit eingebetteten Scripten drin auf dasselbe BOM zugreifen. (Ist bei SVG auch der Fall, andernfalls weiß ich es nicht.)
Habe ich mir gedacht, dass du da zu widersprechen weißt :-). Gibt es überhaupt Browser, die XML einfach so darstellen können? Dazu braucht es doch meines Wissens ein XSLT, das erst mal in HTML oder XHTML übersetzt. OK, andere Formate könnten natürlich prinzipiell "mit eingebetteten Scripten drin auf dasselbe BOM zugreifen". Wäre mal interessant zu wissen, wie sich das BOM z.B. von PDF aus gesehen darstellt. Ich vermute intern eine Hierarchie wie window->document>object->eingebettetes PDF, HTML lässt grüßen (<html><body><object>).
Gruß, Don P
Hallo,
Gibt es überhaupt Browser, die XML einfach so darstellen können?
Wenn das XML-Derivat dem Browser nicht bekannt ist, hat er natürlich keine Regeln zur Darstellung; es wird dann der Elementenbaum angezeigt. Prinzipiell kann man jedes XML-Dokument mit CSS formatiern und mit DOM-Scripting-Logik versehen. Und für manche Funktionalitäten gibt es zentrale XML-Derivate wie XLink.
Wäre mal interessant zu wissen, wie sich das BOM z.B. von PDF aus gesehen darstellt.
http://www.adobe.com/devnet/acrobat/javascript.html
Mathias
Hallo Christian,
der Trick ist bei der Kosntruktion das Objekt-This einer closurevariablen zuzuweisen (z.B. self) über die man dann immer zugreift.
http://forum.de.selfhtml.org/archiv/2008/4/t169341/#m1105915
Oder du machst die aufzurufende Funktion direkt zu einer Methode des Eventgebers, was manchmal viel Sinn macht...
So long
LanX
Hi,
Problem ist nun, dass this in methode1 nicht mehr auf obj zeigt, sondern irgendwo anders hin.
Der ultimative Artikel zu diesem Thema
Gruesse, Joachim
Hallo,
Dazu übergebe ich die methode, also obj.methode1 an eine Funktion, die meine Events handelt, und rufe sie darin auf:
raiseMyEvent: function(handler)
{
handler(); // handler ist z.B. obj.methode1
}
Funktionen haben keine Zugehörigkeit zu irgendeinem Objekt, d.h. generell, ein Objekt hat keine Zugehörigkeit zu einem anderen Objekt, an dem es zwischendurch man dranhängt (ich nenne es mal »Elternobjekt«).
this drückt einfach nur diese Elternobjekt-Unterobjekt-Beziehung aus. Und zwar nur in dem Fall, dass die Funktion auch auf diese Weise aufgerufen wird: obj.methode1().
Wenn man Funktionen als Objekte übergibt oder irgendwo anders speichert - und nichts anderes passiert, wenn du element.onevent = handlerfunktion; notierst -, dann ist der »Kontext«, wie man diese Beziehung nennt, passé. this drückt halt keine wesenhafte Verbindung zwischen Objekten aus, sondern wird situativ bestimmt (deshalb kann man mit apply auch beliebig daran schrauben).
Ähnliches ist, wenn ich schreibe:
var test = obj.methode1;
test();dann ist this auch anders.
Du legst hier eine zweite Referenz auf ein Funktionsobjekt an. Innerhalb einer Funktion als lokale Variable, außerhalb als Methode von window. In beiden Fällen ist this == window, das globale Objekt ist der Fallback-Kontext, sofern kein speziellerer existiert).
Es gibt eben keine »ursprüngliche« Zugehörigkeit zu obj, die Referenz obj.methode1 ist gleichwertig zu test. Beide verweisen nur auf eine Speicherstelle und this bestimmt sich bloß durch die Art und Weise, wie diese Funktion dann tatsächlich aufgerufen wird (test() versus obj.methode1()).
aber das ist ja irgendwie blöd, und für erstes problem auch nicht mehr machbar.
Ja, doch, siehe bind bzw. bindAsEventListener im von Joachim verlinkten Artikel.
Mathias