mozilla
Vos résultats de recherche

    Components.utils.import

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


    Étiquettes et contributeurs liés au document

    Contributors to this page: BenoitL, Mgjbot
    Dernière mise à jour par : Mgjbot,