Allgemeine Gründe, sich nicht mit dem Prototyp von Documents und Elements zu befassen

8

Gibt es allgemeine Gründe, sich nicht mit dem Prototyp von Documents und Elements zu befassen?

Ich mag es, ein eigenes kleines Framework zu erstellen, weil mein aktuelles Projekt nicht die Masse an Features der bestehenden Frameworks benötigt.

Ich muss keine Browser unterstützen, die Element / Document-constructor nicht unterstützen und auch keine Skripts ausführen, die nicht unter meiner Kontrolle stehen.

Würdest du also empfehlen, den Prototyp zu erweitern, oder sollte ich den üblichen Weg gehen und eigene Objekte aus Element / Dokument erstellen?

    
Dr.Molle 29.09.2010, 23:23
quelle

2 Antworten

8

Möchten Sie die Standard-DOM-Elemente erweitern? Wenn ja, bitte nicht. Juriy Zaytsev (alias Kangax) beschreibt klar, warum nicht Was ist los mit der Erweiterung des DOM .

    
Marcel Korpel 29.09.2010, 23:57
quelle
6

Ja, leider. Es wäre schön, Funktionalität hinzufügen zu können, indem man an den DOM-Prototypen fummelt, aber in der Praxis ist es angesichts der heutigen Technologie einfach nicht zuverlässig.

Document , Element und andere usw. können "Host-Objekte" sein, die vom Browser implementiert werden und nicht in der Lage sind, mit ihren Prototypen herumzuspielen. Host-Objekte können möglicherweise viele andere seltsame Verhaltensweisen aufweisen, die ein natives JavaScript-Objekt nicht hätte. DOM-Knoten sind Host-Objekte in IE6-7 und vielen älteren, Nischen- und mobilen Browsern.

Selbst wenn sie als Native-JavaScript-Objekte implementiert sind, gibt es (noch) keinen Standard, wo die Konstruktorfunktion für sie zu finden ist, damit Sie in .prototype fischen können. Document , Element usw. sind nur W3-DOM-Schnittstellennamen, sie sagen nichts darüber aus, was die Implementierungsobjekte sind.

Es kommt vor, dass moderne Browser (IE8 nativer Modus und neuere Versionen von Firefox, Opera und WebKit) Konstruktorfunktionen zur Verfügung stellen, so dass Sie Methoden zu Document oder HTMLElement hinzufügen können. Aber selbst dann gibt es Unterschiede zwischen den freigelegten Objekten, da nicht jeder Browser die DOM-Schnittstellen mit Implementierungen unter den gleichen Namen versorgt. (Die Subschnittstellen / Implementierungen von NodeList sind besonders problematisch.)

Sie können in der Praxis sehen, wie das DOM-Prototyping funktioniert, indem Sie sich das Prototype.js-Framework ansehen. Wenn es funktioniert, ist es super glatt. Aber weil Sie nicht überall prototypieren können, haben Sie am Ende einige extrem hässliche Sachen, wo das Framework mit Orten umgehen muss. Prototyping funktioniert nicht, indem Methoden in jede Instanz eines Nodes kopiert werden. Und dann hast du die Situation, in der dein Code vergessen könnte, dass er diese "Augmentation" erzwingt und es funktioniert oder nicht funktioniert, abhängig davon, ob eine andere Funktion den selben Knoten vorher vergrößert hat. Dies führt zu wirklich schrecklichen browserspezifischen, interaktionsreihenspezifischen, race-conditions-anfälligem Debugging-Schmerz.

Wenn Sie Ihre Prototyping-Arbeit auf einige gut unterstützte Schnittstellen beschränken und alle außer den neuesten Browsern aufgeben können, werden Sie wahrscheinlich damit durchkommen.

    
bobince 30.09.2010 00:06
quelle