En fait, ils ont tendance à avoir une structure
(function($) {
// plugin-code
})(jQuery);
les points étant que
- ils peuvent supposer que $ dans ce champ sera toujours jQuery, indépendamment de toute autre charge qui définit $ par exemple prototype
- tout est défini à l'intérieur de cette fermeture et donc seulement ce que vous choisissez d'exposer (par
$.fn
ou $.extend
) est une fuite vers le monde extérieur
Il est évident que si c'est juste votre plugin dans votre environnement où vous pouvez prendre vous utilisez toujours $ = jQuery alors vous n'en avez pas besoin. (Le vôtre a aussi le document et la fenêtre: je n'ai jamais vu ces substitutions et je ne suis pas sûr de ce que vous passeriez ici comme arguments autres que le document et la fenêtre?)
Avez-vous demandé de définir des données dans le plugin ou en tirant de l'extérieur de la portée du plugin? Il n'y a pas de restrictions sur ce que vous pouvez écrire à l'intérieur, donc si vous le définissez et l'utilisez à l'intérieur, votre code fonctionnera exactement comme befoer. Si vous avez besoin d'accéder à des données définies de l'extérieur, vous aurez besoin de les filtrer d'une manière ou d'une autre, par ex. ajouter une méthode d'accès à l'un de $, document ou fenêtre.
Si vous extrayez des données de l'extérieur de la portée du plugin, vous pouvez toujours accéder aux variables globales à l'intérieur de votre clôture, ou vous pouvez les passer en argument supplémentaire - je ne pense pas que cela ferait une différence .
Oui, cela devrait être possible (sauf si l'identificateur 'data' a été éclipsé par une variable/un argument plus local dans le plug-in). –