n'abend,
HIIILLFEEE!!11fünfundzwanzigzwölf ;)
Ich bastle derzeit an (m)einem kleinen Javascript Framework. (Bemerkungen a la "Warum nutzt du nicht $insertRandomJsFramework?" darf man sich sparen. Würde ich diese Dinger nutzen wollen, würde ich es tun.)
Natürlich soll das System resistent gegen fremde ebenfalls geladene Scripts / Bibliotheken / Frameworks sein und diese in ihrer Funktionsweise auch nicht beeinflussen. Es soll also nicht möglich sein, dass eigene Komponenten von etwas anderem überschrieben werden, oder dass eine eigene Komponente etwas anderes überschreibt. So viel Anspruch darf sein. Das Gestaltet sich bei Utiltites und Widgets ja recht einfach, stellt mich beim "Erweitern bestehender Objekte" vor eine dicke Mauer.
Beispielhaft betrachten wir im Folgenden Nodes und eine hinzuzufügende Methode dummy().
Möglichkeit 1 - das Offensichtliche
Node.prototype.dummy = function(){ alert( this.className ); };
document.body.dummy();
Prototyping dieser Form hat den Nachteil, dass ein anderes dahergelaufenes Script ebenfalls Node prototypisch um dummy() erweitern könnte, allerdings mit einer komplett anderen funktionsweise, als ich diese erdacht habe. Das wäre für mein Framwork eher schlecht, fast so schlecht, als würde mein Framework auf die selbe Art und Weise Prototypen anderer Systeme überschreiben.
Möglichkeit 2 - das Unbrauchbare
fw.utils.Node.dummy = function( nodeObject ){ alert( nodeObject.className ); };
fw.utils.Node.dummy( document.body );
Nun, das erinnert irgendwie an komisch strukturierte, nicht-OOP Konzeption. Kann es nicht sein.
Möglichkeit 3 - die Augenwischerei
fw.utils.Node.dummy = function(){ alert( this.className ); };
document.myGetElementById = function( id )
{
var el = document.getElementById(id);
el.dummy = fw.utils.Node.dummy;
return el;
};
document.myGetElementById('demo').dummy()
Dieses Verfahren wird gerne von anderen Frameworks angewendet. Man nutzt eigene Methoden um Elemente zu erstellen Nodes im DOM zu finden. Man erweitert die Objekte in diesen Funktionen um die Methoden, die man eben nicht prototypisch hinzugefügt hat und gibt die erweiterte Node wieder zurück. Das ist ja schön, bewirkt aber für die gefundenen Nodes "das gleiche" wie die prototypische Erweiterung: ich könnte eine Methode eines anderen Systems überschreiben.
Möglichkeit 4 - die Verkapselei
function MyNode( base )
{
/* durchpipen der Attribute von base */
this.dummy = function(){ alert(base.className) };
}
document.myGetElementById = function( id )
{
var el = document.getElementById(id);
return new MyNode( el );
}
Tja, auf den ersten Blick sieht es ganz angenehm aus das original Objekt unangetastet zu lassen, es in einem anderen Objekt zu kapseln und durch die Kapsel alle erweiternden Methoden zur Verfügung zu stellen. Irgendwie müssen dann aber die Attribute der Node in MyNode verfügbar gemacht werden. Wie will man das denn bitte sinnvoll machen? Es soll ja Methoden und Attribute geben, die man nicht in einem for(..in..) wiederfindet, weil sie "versteckt" sind. Dann stellt sich die Frage ob es nicht sinnvoller ist, "statische" Kapseln zu bauen, also die bekannten Attribute in die Definition packen, statt darüber zu iterieren?
Möglichkeit 5 - die ProtoypeNamespaces
document.body.FrameworkNamespace.dummy()
Sowas in dieser Art wäre mir glaube ich am liebsten. Allerdings fehlen mir (funktionierende) Ansätze das umzusetzen.
weiterhin schönen abend...
Freundlich wie man war, hat man mir Großbuchstaben geschenkt.
sh:( fo:# ch:# rl:| br:> n4:& ie:{ mo:} va:) de:] zu:} fl:( ss:? ls:[ js:|