prototype et coexistence pacifique de jQuery?

Question

Je sais très peu de choses sur JavaScript, mais malgré cela, j'essaie de bricoler quelque chose sur mon blog wordpress. Cela ne fonctionne pas, et je ne sais pas comment le résoudre, et bon, c'est à ça que sert StackOverflow, non?

Tout d'abord, le message d'erreur est le suivant:

Error: element.dispatchEvent is not a function
Source File: http://.../wp-includes/js/prototype.js?ver=1.6
Line: 3936

Cela se produit au chargement de la page. Mon gestionnaire de chargement de page est enregistré comme suit:

Event.observe(window, 'load', show_dates_as_local_time);

L'erreur disparaît si je désactive d'autres plugins, ce qui m'a conduit à conclure qu'il s'agissait d'un conflit entre prototype et jQuery (utilisé par certains des autres plugins).

Deuxièmement, je suis la pratique recommandée par wordpress d'utiliser wp_enqeue_script pour ajouter une dépendance de mon JavaScript à la bibliothèque Prototype, comme suit:

add_action( 'wp_print_scripts', 'depo_theme_add_javascript' );

function depo_theme_add_javascript() {
    wp_enqueue_script('friendly_dates', 'javascript/friendly_dates.js', array('prototype'));
}

Maintenant, je suis également conscient qu'il existe des conflits potentiels entre jQuery et Prototype qui sont résolus à l'aide de la méthode jQuery noConflicts . J'ai essayé d'appeler ça de divers endroits mais ce n'est pas bon. Je ne pense pas que ce soit le problème car a) la fonction noConflict concerne uniquement la variable $ , qui ne semble pas être le problème ici, et b) je je m'attendrais wordpress à régler le problème pour moi car il peut ...

Enfin, en utilisant le débogueur Venkman, j'ai déterminé que l'élément référencé dans le message d'erreur est bien un HTMLDocument mais manque également d'un dispatchEvent . Vous ne savez pas comment cela pourrait se produire, étant donné qu'il s'agit d'une méthode DOM standard?

Answer 1

Merci à tous pour les suggestions. En fin de compte, je pense que l’explication de Kent était la plus proche, c’est-à-dire que "Prototype est cassé". (Désolé si je ne vous résume pas correctement):

En ce qui concerne l'option jQuery.noConflict - je l'ai déjà mentionné dans la question. Cela fait une différence lorsque vous exécutez cette méthode, et j’ai très peu de contrôle sur cela. Comme je l'ai dit, j'ai essayé de l'exécuter à différents endroits (notamment l'en-tête de page et également à partir de mon fichier de script), sans aucun effet. Donc, comme nous le souhaiterions tous, "utilisez simplement noConflict ". N'est pas une réponse à cette question, du moins sans informations supplémentaires.

En outre, jQuery.noConflict semble concerner la variable $ et le code autour du point d'erreur ne traite pas cette variable. du tout. Bien sûr, ils pourraient être liés indirectement, je ne l'ai pas retrouvé.

En gros, j’ai fini par réécrire le script en utilisant jQuery au lieu de Prototype, qui posait en fait ses propres problèmes. Quoi qu'il en soit, j'ai publié l'intégralité de article de guerre sur mon blog , si cela vous intéresse.

Answer 2

Il existe un truc méchant dans lequel de nombreuses bibliothèques se passaient, et il semble que le prototype en fait partie.

Mootools fait cela, si je ne me trompe pas, et cela implique de surcharger de nombreux prototypes sur les classes de base, en les corrigeant.

De même, j’ai rencontré le même comportement étrange lorsque mootools et jQuery étaient présents, jquery mourant généralement parce qu’il appelait une méthode objet qui avait été surchargée / corrigée par singe et corrigée par Mootools.

En outre, mystérieusement, le fait de supprimer mootools de la liste d’utilisation des scripts a rendu tout tout beaucoup plus rapide, ce qui, j’en ai conclu, était dû à une pollution moindre des objets.

Maintenant, je peux me tromper, mais j’ai conclu de mon expérience que de telles bibliothèques n’aimaient tout simplement pas coexister les unes avec les autres et, voyant à quel point le code mootools me semblait dégrader la vitesse à laquelle les choses normales étaient faites, aspiré et porté tout le code basé sur mootools sur jQuery (une affaire qui prend beaucoup de temps, je vous assure), et le résultat est un code qui était rapide et sans erreurs étranges qui étaient inexplicables.

Je vous recommande de considérer la migration comme au moins une option.

Encore une chose en écrivant:

J'ai tendance à utiliser cette syntaxe avec tout mon code basé sur jQuery, pour un peu d'encapsulation en toute sécurité dans le cas où quelqu'un casse '$' d'une manière ou d'une autre.

Code d'exécution Ceci attend document.ready avant d'exécuter:

 jQuery(function($){ 
      code_with_
 Il existe un truc méchant dans lequel de nombreuses bibliothèques se passaient, et il semble que le prototype en fait partie. 

 Mootools fait cela, si je ne me trompe pas, et cela implique de surcharger de nombreux prototypes sur les classes de base, en les corrigeant. 

 De même, j’ai rencontré le même comportement étrange lorsque mootools et jQuery étaient présents, jquery mourant généralement parce qu’il appelait une méthode objet qui avait été surchargée / corrigée par singe et corrigée par Mootools. 

 En outre, mystérieusement, le fait de supprimer mootools de la liste d’utilisation des scripts a rendu  tout  tout beaucoup plus rapide, ce qui, j’en ai conclu, était dû à une pollution moindre des objets. 

 Maintenant, je peux me tromper, mais j’ai conclu de mon expérience que de telles bibliothèques n’aimaient tout simplement pas coexister les unes avec les autres et, voyant à quel point le code mootools me semblait dégrader la vitesse à laquelle les choses normales étaient faites, aspiré et porté tout le code basé sur mootools sur jQuery (une affaire qui prend beaucoup de temps, je vous assure), et le résultat est un code qui était  rapide   et  sans erreurs étranges qui étaient inexplicables. 

 Je vous recommande de considérer la migration comme au moins  une  option. 

  Encore une chose en écrivant:  

 J'ai tendance à utiliser cette syntaxe avec tout mon code basé sur jQuery, pour un peu d'encapsulation en toute sécurité dans le cas où quelqu'un casse '$' d'une manière ou d'une autre. 

  Code d'exécution 
Ceci attend document.ready avant d'exécuter: 

(function($){ 
    code_with_
 Il existe un truc méchant dans lequel de nombreuses bibliothèques se passaient, et il semble que le prototype en fait partie. 

 Mootools fait cela, si je ne me trompe pas, et cela implique de surcharger de nombreux prototypes sur les classes de base, en les corrigeant. 

 De même, j’ai rencontré le même comportement étrange lorsque mootools et jQuery étaient présents, jquery mourant généralement parce qu’il appelait une méthode objet qui avait été surchargée / corrigée par singe et corrigée par Mootools. 

 En outre, mystérieusement, le fait de supprimer mootools de la liste d’utilisation des scripts a rendu  tout  tout beaucoup plus rapide, ce qui, j’en ai conclu, était dû à une pollution moindre des objets. 

 Maintenant, je peux me tromper, mais j’ai conclu de mon expérience que de telles bibliothèques n’aimaient tout simplement pas coexister les unes avec les autres et, voyant à quel point le code mootools me semblait dégrader la vitesse à laquelle les choses normales étaient faites, aspiré et porté tout le code basé sur mootools sur jQuery (une affaire qui prend beaucoup de temps, je vous assure), et le résultat est un code qui était  rapide   et  sans erreurs étranges qui étaient inexplicables. 

 Je vous recommande de considérer la migration comme au moins  une  option. 

  Encore une chose en écrivant:  

 J'ai tendance à utiliser cette syntaxe avec tout mon code basé sur jQuery, pour un peu d'encapsulation en toute sécurité dans le cas où quelqu'un casse '$' d'une manière ou d'une autre. 

  Code d'exécution 
Ceci attend document.ready avant d'exécuter: 

 jQuery(function($){ 
      code_with_
 Il existe un truc méchant dans lequel de nombreuses bibliothèques se passaient, et il semble que le prototype en fait partie. 

 Mootools fait cela, si je ne me trompe pas, et cela implique de surcharger de nombreux prototypes sur les classes de base, en les corrigeant. 

 De même, j’ai rencontré le même comportement étrange lorsque mootools et jQuery étaient présents, jquery mourant généralement parce qu’il appelait une méthode objet qui avait été surchargée / corrigée par singe et corrigée par Mootools. 

 En outre, mystérieusement, le fait de supprimer mootools de la liste d’utilisation des scripts a rendu  tout  tout beaucoup plus rapide, ce qui, j’en ai conclu, était dû à une pollution moindre des objets. 

 Maintenant, je peux me tromper, mais j’ai conclu de mon expérience que de telles bibliothèques n’aimaient tout simplement pas coexister les unes avec les autres et, voyant à quel point le code mootools me semblait dégrader la vitesse à laquelle les choses normales étaient faites, aspiré et porté tout le code basé sur mootools sur jQuery (une affaire qui prend beaucoup de temps, je vous assure), et le résultat est un code qui était  rapide   et  sans erreurs étranges qui étaient inexplicables. 

 Je vous recommande de considérer la migration comme au moins  une  option. 

  Encore une chose en écrivant:  

 J'ai tendance à utiliser cette syntaxe avec tout mon code basé sur jQuery, pour un peu d'encapsulation en toute sécurité dans le cas où quelqu'un casse '$' d'une manière ou d'une autre. 

  Code d'exécution 
Ceci attend document.ready avant d'exécuter: 

<*>

  Plug-ins jQuery  

<*>

 Leur utilisation facilitera la tâche des personnes  qui utilisent  n’importe quel jQuery que vous écrivez pour pouvoir l’utiliser sans trop de problème de conflit. 

 Cela leur permettra essentiellement de s’assurer que leur code ne fait rien de vraiment magique. 
here; 
 }); 


  Plug-ins jQuery  

<*>

 Leur utilisation facilitera la tâche des personnes  qui utilisent  n’importe quel jQuery que vous écrivez pour pouvoir l’utiliser sans trop de problème de conflit. 

 Cela leur permettra essentiellement de s’assurer que leur code ne fait rien de vraiment magique. 
here; 
})(jQuery); 


  Plug-ins jQuery  

<*>

 Leur utilisation facilitera la tâche des personnes  qui utilisent  n’importe quel jQuery que vous écrivez pour pouvoir l’utiliser sans trop de problème de conflit. 

 Cela leur permettra essentiellement de s’assurer que leur code ne fait rien de vraiment magique. 
here; 
 }); 

Plug-ins jQuery

<*>

Leur utilisation facilitera la tâche des personnes qui utilisent n’importe quel jQuery que vous écrivez pour pouvoir l’utiliser sans trop de problème de conflit.

Cela leur permettra essentiellement de s’assurer que leur code ne fait rien de vraiment magique.

Answer 3

Cela vaut la peine de lire cet article sur le site JQuery à propos de Utilisation de JQuery avec d'autres bibliothèques . Il ne s'agit pas que de l'option noConflict.

Answer 4

Je pense que vous devriez bien chercher, car tous les plugins jQuery ont une version prototype et tous les plugins prototypes ont une version jQuery. Si vous ne trouvez vraiment pas ce que vous cherchez et que vous ne pouvez pas utiliser une seule bibliothèque, consultez ici sur

jQuery.noConflict();

Mais encore une fois, je pense qu'il est inutile de charger plus de 15-20 Ko pour chaque bibliothèque:)