2009-08-21 11 views
0

Ich habe gerade fast 2 Stunden damit verbracht, eine JavaScript-Bibliothek eines Drittanbieters zu debuggen, nur um festzustellen, dass ein Array, das ich an diese Bibliothek übergebe, irgendwo in der Pipe in eine Zeichenkette umgewandelt wird ... Ich weiß nicht warum oder wie das passiert Sobald ich Prototype aus meinem Projekt entferne, funktioniert alles wieder gut.Die DOM-Erweiterungen von Prototype kollidieren mit einer JS-Bibliothek von Drittanbietern - was ist meine beste Entscheidung?

Könnte das daran liegen, dass Prototyp das DOM erweitert? Was ist meine beste Wahl? Ich benutze die Element-Iteratoren von Prototype, die DOM-Manipulation, die bind() -Methode und die String-Manipulatoren in meinem Projekt und möchte sie lieber nicht verlieren.

Gibt es eine Bibliothek, die all das hat, aber die mit JS-Bibliotheken von Drittanbietern funktioniert, die empfindlich auf DOM-Erweiterungen reagieren?

Antwort

2

Nachdem wir in der Vergangenheit mit Prototype gearbeitet haben, gibt es keine Möglichkeit, es "schön spielen" zu lassen (ähnlich dem noConflict-Modus von jQuery).

Der Ansatz hinter Prototype verhindert dies. Prototypes Brot & Butter kommt von seiner Object.extend() -Methode, die Objekte aufgerufen wird, sobald Sie sie mit Prototype-Methoden manipulieren. Ganz zu schweigen davon, dass Prototype auch bereits Kern-JavaScript-Objekte modifiziert hat, bevor Sie sich mit Ihnen herumschlagen.

Auf der anderen Seite ist jQuery im jQuery-Objekt (das nach meinem Wissen alles zum JavaScript-Namespace hinzugefügt wird, wenn es enthalten ist) vollständig eigenständig.

Gibt es andere Bibliotheken, die ähnliche Funktionen haben? Sicher, in der Tat, und ich bin sicher, dass Sie es satt haben, das jetzt zu hören, aber Sie könnten wahrscheinlich das meiste mit jQuery machen. Sie vermeiden jedoch nicht das Unvermeidliche: Code neu schreiben. Es wird nicht auf die gleiche Weise mit irgendeinem anderen Rahmen gemacht, geschweige denn, Ihnen die gleichen Ergebnisse zu geben.

Ihre Entscheidungen sind somit:

  • Tropfen Prototype und neu zu schreiben Sachen, die es etwas anderes
  • Tropfen der Dritte Bibliothek zugunsten alternativer oder Abwesenheit völlig
  • Re- verwenden nicht genutzt schreibe prototype.js oder thirdpartytool.js, um gut zu spielen (das ist natürlich ein schrecklicher Hack, der dir mehr Kopfschmerzen bereitet, wenn du eines oder beide Tools in der Zukunft "upgraden" willst, wenn eine neue Version herauskommt)
+0

Ich sollte beachten, dass beide Prototypen und jQuery beide ihre Stärken haben. Ich vermisse häufig Fähigkeiten von jedem, wenn Projekt x, an dem ich arbeite, nur eines von ihnen verwenden kann. Aber das ist es eben: Ich habe es absichtlich vermieden, die beiden zu mischen. –

+0

Danke für deine Antwort. Ich benutze jetzt jQuery und die Punkt-String-Erweiterung (weil ich mich stark auf String-Normalisierung verlassen). Ich vermisse immer noch einige Dinge wie eine Art "dieses" zu binden, aber die meisten Dinge, die ich brauche, sind da. – Matthias

0

Ich hatte Erfolg mit jQuery. Wenn Sie jQuery.noConflict() aufrufen, funktioniert es sehr gut mit anderen JS-Bibliotheken.

+0

Dank für den Zeiger ist das Problem jedoch nicht, dass die Variable $ mit anderen Bibliotheken kollidiert. Es sind die Objekterweiterungen, die Prototype anwendet, die den Ärger verursachten. – Matthias

+0

Nein, das verstehe ich.JQuery ist nett darin, dass es viel von der gleichen Funktionalität enthält, aber ohne die Objekterweiterungen, die Probleme mit Prototyp und Mootools verursachen können –

0

Ein bisschen meiner bitteren Erfahrung.

Ich habe gerade mein eigenes Framework für XUL-Anwendungen fertig geschrieben (ich brauche nur so etwas wie ein Komponentenmodell ohne $ oder Prototyp lib süsse). Es ist sehr klein, handlich und unkompliziert. Aber ... Erst jetzt, wenn alles bereit ist, das Framework zu verwenden, habe ich festgestellt, dass es im XUL-Kontext absolut tot ist. Das Haupthindernis ist, dass die JavaScript-Engine alle Änderungen an den Basisobjekten wie Function, Object usw. verwirft. Also die Schlüsselerweiterungen, die die Dinge funktionieren lassen — f.x. Function.prototype.toClass, override und andere — sind unsichtbar außerhalb der Datei, wo sie definiert sind.