Components.utils.import

Un article de MDC.

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.

[modifier] 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 URI resource: (celles-ci sont à documenter).