Cette méthode a été introduite dans Firefox 3 et est utilisée pour partager aisément du code entre différentes visibilités. Par exemple, il est possible d'importer XPCOMUtils.jsm pour éviter de copier/coller de longs pavés d'enregistrement de composants XPCOM dans vos fichiers de composants.
Consultez le bug 238324, la documentation dans xpccomponents.idl ainsi que les tests dans js/src/xpconnect/tests/unit/
pour plus de détails et des exemples.
Différences avec mozIJSSubScriptLoader
Les différences avec mozIJSSubScriptLoader
sont les suivantes :
- Le comportement d'importation/chargement du même code depuis différents emplacements :
- le chargeur de sous-script évalue le code indiqué à chacune de ses invocations, avec l'objet global de l'appelant.
Components.utils.import
évalue le code de chaque module une seule fois, dans sa propre visibilité.
Par exemple :
var scope1 = {}, scope2 = {}; Components.utils.import("rel:XPCOMUtils.jsm", scope1); Components.utils.import("rel:XPCOMUtils.jsm", scope2); assert(scope2.XPCOMUtils === scope1.XPCOMUtils);
à comparer avec :
var obj1 = {}, obj2 = {}; var loader = Components.classes["@mozilla.org/moz/jssubscript-loader;1"] .getService(Components.interfaces.mozIJSSubScriptLoader); loader.loadSubScript(someURL, obj1) loader.loadSubScript(someURL, obj2) assert(obj1.XPCOMUtils === obj2.XPCOMUtils);
Cela signifie que
Components.utils.import
est plus adapté pour le partage efficace de code (et de données ?) entre différents scripts exécutés dans des visibilités différentes. - Le chargeur de sous-script accepte une URL vers le code à charger, tandis qu'
import
n'accepte que des URIresource:
(celles-ci sont à documenter).