mozilla

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

Contributeurs à cette page : BenoitL, Mgjbot
Dernière mise à jour par : Mgjbot,