From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- files/fr/mozilla/tech/index.html | 13 + .../index.html | 37 ++ .../an_overview_of_xpcom/index.html | 504 +++++++++++++++++++++ .../xpcom/guide/creating_components/index.html | 281 ++++++++++++ .../guide/creating_components/preface/index.html | 77 ++++ .../using_xpcom_components/index.html | 303 +++++++++++++ files/fr/mozilla/tech/xpcom/guide/index.html | 16 + files/fr/mozilla/tech/xpidl/index.html | 22 + 8 files changed, 1253 insertions(+) create mode 100644 files/fr/mozilla/tech/index.html create mode 100644 files/fr/mozilla/tech/visualisation_et_recherche_du_code_source_mozilla_en_ligne/index.html create mode 100644 files/fr/mozilla/tech/xpcom/guide/creating_components/an_overview_of_xpcom/index.html create mode 100644 files/fr/mozilla/tech/xpcom/guide/creating_components/index.html create mode 100644 files/fr/mozilla/tech/xpcom/guide/creating_components/preface/index.html create mode 100644 files/fr/mozilla/tech/xpcom/guide/creating_components/using_xpcom_components/index.html create mode 100644 files/fr/mozilla/tech/xpcom/guide/index.html create mode 100644 files/fr/mozilla/tech/xpidl/index.html (limited to 'files/fr/mozilla/tech') diff --git a/files/fr/mozilla/tech/index.html b/files/fr/mozilla/tech/index.html new file mode 100644 index 0000000000..c624ad5a70 --- /dev/null +++ b/files/fr/mozilla/tech/index.html @@ -0,0 +1,13 @@ +--- +title: Technologies de Mozilla +slug: Mozilla/Tech +tags: + - Mozilla + - Reference + - Régionalisation + - XUL +translation_of: Mozilla/Tech +--- +

Mozilla a plusieurs technologies utilisées en composantes de ses projets. Celles-ci sont documentées ici.

+ +

{{LandingPageListSubpages}}

diff --git a/files/fr/mozilla/tech/visualisation_et_recherche_du_code_source_mozilla_en_ligne/index.html b/files/fr/mozilla/tech/visualisation_et_recherche_du_code_source_mozilla_en_ligne/index.html new file mode 100644 index 0000000000..bdbde7f35c --- /dev/null +++ b/files/fr/mozilla/tech/visualisation_et_recherche_du_code_source_mozilla_en_ligne/index.html @@ -0,0 +1,37 @@ +--- +title: Visualisation et recherche du code source Mozilla en ligne +slug: Mozilla/Tech/Visualisation_et_recherche_du_code_source_Mozilla_en_ligne +tags: + - Developper avec Mozilla + - Mozilla Code source +translation_of: Mozilla/Tech/Viewing_and_searching_Mozilla_source_code_online +--- +

Le code source pour tous les projets de Mozilla hébergés dans le dépôt Mercurial et CVS peut être recherché et consulté en ligne à l'aide de DXR. C'est une variante renforcée et améliorée de l'outil original Linux Cross Reference.

+ +

Ne téléchargez pas le code source en parcourant toutes les pages du site DXR ; téléchargez plutôt une archive ou utilisez Mercurial ou CVS à la place.
+
+ DXR indexe plusieurs branches CVS et modules; la racine MXR la plus intéressant pour un contributeur Mozilla est comm-central, qui contient le dernier code source pour la plupart des produits Mozilla (y compris Firefox, Thunderbird, SeaMonkey, Sunbird / Lightning Chatzilla, DOM Inspector et Venkman JavaScript debugger) et est fréquemment mise à jour.

+ +

Certaines autres racines d'intérêt MXR sont:

+ + + +

Mozilla Source Code Directory Structure (page en Anglais) contient une courte description du code dans chaque répertoire source de l'arbre.

+ +

Ressources

+ +

CVS Tags

diff --git a/files/fr/mozilla/tech/xpcom/guide/creating_components/an_overview_of_xpcom/index.html b/files/fr/mozilla/tech/xpcom/guide/creating_components/an_overview_of_xpcom/index.html new file mode 100644 index 0000000000..35e8dd51a0 --- /dev/null +++ b/files/fr/mozilla/tech/xpcom/guide/creating_components/an_overview_of_xpcom/index.html @@ -0,0 +1,504 @@ +--- +title: Un aperçu de XPCOM +slug: Mozilla/Tech/XPCOM/Guide/Creating_components/An_Overview_of_XPCOM +translation_of: Mozilla/Tech/XPCOM/Guide/Creating_components/An_Overview_of_XPCOM +--- +

+

« PrécédentSuivant »

+

+ +

Cette section est présentée comme un tutoriel sur la création de composants XPCOM, mais elle couvre tous les principaux aspects, les concepts et la terminologie du modèle de composant XPCOM tout au long de sa conception.

+ +

Ce chapitre fournit un rapide tour d'horizons sur XPCOM - une introduction aux concepts de base, des technologies XPCOM et du développement de composants. Les paragraphes de ce chapitre présentent des concepts de haut niveaux, de sorte que nous puissions les approfondir et de les utiliser avec plus de familiarité dans le tutoriel lui-même, qui décrit la création d'un composant Mozilla appelé WebLock .

+ +

La solution XPCOM

+ +

Le Cross Platform Component Object Module (XPCOM) est un cadre qui permet aux développeurs de fractionner un projets monolithiques en morceaux modulaires. Ces morceaux, appelés composants , sont ensuite assemblés de nouveau ensemble à l'exécution.

+ +

Le but de XPCOM est de mettre au point les différentes parties de logiciel en les construisant indépendamment les uns des autres. Afin de permettre l'interopérabilité entre les composants d'une application, XPCOM sépare la mise en œuvre d'un composant de l'Interface . Mais XPCOM fournit également plusieurs outils et bibliothèques qui permettent le chargement et la manipulation de ces composants, des services qui aident le développeur à écrire du code modulaire multi-plateforme, et le soutien des versions, de sorte que les composants peuvent être remplacés ou mis à niveau sans casser ou avoir à recréer l'application . En utilisant XPCOM, les développeurs créent des composants qui peuvent être réutilisés dans différentes applications ou qui peut être remplacé pour changer la fonctionnalité des applications existantes.

+ +

XPCOM soutient non seulement le développement de composant logiciels, il fournit également une grande partie des fonctionnalité de la plate-forme de développement fournit, tels que:

+ + + +

Nous allons décrire les éléments ci-dessus en détail dans les chapitres à venir, mais pour l'instant, il peut être utile de penser à XPCOM en tant que plate-forme pour le développement de composants , dans lequel des caractéristiques telles que celles énumérées ci-dessus sont fournis.

+ +

Gecko

+ +

Bien qu'il soit à certains égards structurellement similaires à Microsoft COM, XPCOM est conçu pour être utilisé principalement au niveau de l'application. L'utilisation la plus importante de XPCOM est dans Gecko , open source, conforme aux standards, navigateur Web intégrable et boîte à outils pour la création de navigateurs Web et autres applications.

+ +

XPCOM est le moyen d'accéder aux fonctionnalités de la bibliothèque Gecko pour l'utilisation ou l'extension de Gecko. Ce livre met l'accent sur l'extension mais les explications de ce livre seront important pour le développeurs d'application Gecko embarquées.

+ +

Gecko est utilisé dans de nombreuses applications internet, la plupart des navigateurs et notamment Mozilla Firefox.

+ +

Composants

+ +

XPCOM vous permet de briser les gros projets logiciels en petits morceaux connus en tant que composants. Ils sont généralement contenus dans des bibliothèques binaires réutilisables (DLL sur Windows, DSO sur Unix), qui peuvent comprendre un ou plusieurs composants. Lorsque deux ou plusieurs composants connexes sont regroupées dans une bibliothèque binaire, la bibliothèque est appelée module.

+ +

Modulaire, la programmation à base de composants logiciels rend plus facile le développement et la maintenance:

+ + + + + + + + + + + + + + + + + + + + + + + + +
AvantageDescription
RéutilisationCode modulaire peut être réutilisé dans d'autres applications et d'autres contextes.
Mises à jourVous pouvez mettre à jour les composants sans avoir à recompiler l'application entière.
PerformanceLorsque le code est modulaire, les modules qui ne sont pas nécessaires immédiatement peuvent être chargées partiellement, ou pas chargés du tout, ce qui peut améliorer les performances de votre application.
MaintenanceMême lorsque un composant est obsolète, la conception de votre application modulaire vous permet  plus facilement de maintenir les parties de l'application que vous intéressent.
+ +

Mozilla a plus de quatre millions de lignes de code, et pas une seule personne ne comprend l'ensemble du code source. La meilleure façon d'aborder un projet de cette taille est de le diviser en modules. La bibliothèque de réseau, par exemple, est constitué de composants pour chacun des protocoles, HTTP, FTP, et d'autres, qui sont groupés et liés dans une seule bibliothèque. Cette bibliothèque est le module de gestion de réseau, également appelé "necko."

+ +

Mais il n'est pas toujours souhaitable de diviser les choses. Le composant HTTP de Gecko n'expose pas les classes privés qu'elle utilise comme des composants séparés. Les objets interne au composante reste interne, et ne soit pas manipulables par XPCOM.

+ +

Interfaces

+ +

Comment segmenter du code? L'idée de base est d'identifier les segments fonctionnellement liés et comprendre comment ils communiquent entre eux. Les canaux de communication entre les différentes composants forment ces limites, et lorsque ces limites sont formalisées on parle d'interfaces .

+ +

Les interfaces ne sont pas une idée nouvelle en programmation. Nous avons tous l'habitude interfacer depuis notre premier programme "HelloWorld", où est l'interface entre le code que nous avons écrit - le code d'application - et le code d'impression. Le code d'application utilisé une interface à partir d'une bibliothèque, stdio , et imprime la texte "hello world" sur l'écran. La différence ici est que l'application "HelloWorld" dans XPCOM trouve cette fonctionnalité d'affichage à l'exécution et n'a pas à connaître stdio quand il est compilé.

+ +

Interfaces permettent aux développeurs d' encapsuler la mise en œuvre et de fonctionnement interne de leur logiciel, et permettent aux clients d'ignorer la façon dont les choses sont faites, il suffit d'utiliser ce logiciel.

+ +
+

Interfaces et programmation par contrat

+ +

Une interface forme un accord contractuel entre les composants et les clients. Il n'y a pas de code qui oblige ces accords, mais les ignorer peut être fatal. Dans la programmation à base de composants, un composant garantit que les interfaces qu'il fournit seront immuable - qu'ils vont offrir le même accès aux mêmes méthodes à travers différentes versions du composante - l'établissement d'un contrat avec les logiciels clients qui l'utilisent. À cet égard, la programmation basé sur l'interface est souvent désigné comme la programmation par contrat .

+
+ +

Interfaces et Encapsulation

+ +

Aux limites des composants, l'abstraction est crucial pour la maintenabilité du logiciel et la réutilisabilité. Considérons, par exemple, une classe mal encapsulé. L'utilisation d'une méthode d'initialisation publique librement disponibles, comme l'exemple ci-dessous, peut causer des problèmes.

+ +

SomeClass Class Initialization

+ +
class SomeClass{
+  public:
+    // Constructeur
+    SomeClass();
+    // Destructeur virtuel
+    virtual ~SomeClass();
+    // method init
+    void Init();
+    void DoSomethingUseful();
+};
+
+ +

Pour que ce système fonctionne correctement, l'utilisateur de cette classe doit porter une attention particulière à tout ce que le créateur de cette classe a établi. C'est l'accord contractuel avec cette classe non encapsulé: un ensemble de règles qui définissent quand chaque méthode peut être appelée et ce qu'elle est censé faire. Une règle peut spécifier que DoSomethingUseful ne peut être appelé après un appel à init () . La méthode DoSomethingUseful peut veiller à ce que la condition soit satisfaite.

+ +

En plus du code correctement commenté pour les règles d'utilisation de Init() , le développeur peut prendre quelques mesures pour que ce contrat soit plus clair. Tout d'abord, le constructeur d'un objet peut être encapsulé, et une classe virtuelle DoSomethingUseful peut être mis à disposition. De cette façon, le constructeur et l'initialisation peuvent être complètement cachés des utilisateurs de la classe. Dans cette situation, "semi-encapsulé", la seule partie de la classe qui est exposé est une liste bien définie des méthodes appelables (i.e, l'interface). Une fois que la classe est encapsulé, la seule interface que le client verra est la suivante:

+ +

Encapsulation de SomeInterface

+ +
class SomeInterface{
+  public:
+    virtual void DoSomethingUseful() = 0;
+};
+
+ +

La mise en œuvre peut alors dériver de cette classe par l'utilisation de la méthode virtuelle. Les utilisateurs de ce code peuvent ensuite créer l'objet (voir utilisation ) et encapsuler aussi la mise en œuvre. Avec XPCOM, les usagers sont ignorant du fonctionnement du composants et comptent sur ​​l'interface pour donner accès aux fonctionnalités nécessaires.

+ +

L'interface de base nsISupports

+ +

Les deux fondamentaux de la programmation composant sont basé sur component lifetime(durée de vie), appelé aussi object ownership, et interface querying, sois l'identification des interfaces d'un composant prises en charge lors de l'exécution. Ce chapitre présente la mère de toutes les interfaces XPCOM - nsISupports , qui fournit les solutions à ces deux problèmes pour les développeurs XPCOM.

+ +

Object Ownership

+ +

Avec XPCOM, parce que les composants peuvent mettre en œuvre un certain nombre d'interfaces, ils doivent être référencés . Quand un composant est créé, un entier interne au composant est incrémenté - connu comme compteur de référence. Au cours de la vie du composant, le compteur de référence augmente et diminue. Lorsque le composant n'a plus d'utilité, le compteur de références atteint zéro, et le composant est détruit.

+ +

Lorsque les clients utilisent des interfaces de façon responsable, cela peut être un processus très simple. XPCOM dispose d'outils pour rendre encore cela plus facile. Il peut soulever des problèmes réels de maintenance lorsque, par exemple, un client utilise une interface et oublie de decrémenter le nombre de références. Lorsque cela se produit, les interfaces ne peuvent jamais être libérés et provoqueront des fuites de mémoire. Le système de comptage de référence est, comme beaucoup de choses dans XPCOM, un contrat entre les clients et les implémentations. Il fonctionne quand les utilisateur le respecte, mais quand ils ne le font pas, les choses peuvent aller mal. C'est le rôle de la fonction qui crée le pointeur d'interface pour ajouter la référence initiale, ou owning reference, d'éviter ces problemes.

+ +
+

Pointeurs avec XPCOM

+ +

Dans XPCOM, les pointeurs se réfèrent à l'interface pointeurs. La différence est subtile, puisque les pointeurs d'interface et les pointeurs réguliers sont tout simplement deux adresses dans la mémoire. Mais un pointeur d'interface est connu pour mettre en œuvre l'interface de base nsISupports, et peut donc être utilisé pour appeler des méthodes telles que AddRef, Release, ou QueryInterface.

+
+ +

nsISupports, illustré ci-dessous, fournit les fonctionnalités de base pour faire face à la création d'interface et de comptage de référence. Les membres de cette interface, QueryInterface, AddRef et Release , fournissent les moyens de base pour obtenir la bonne interface d'un objet, incrémenter le compteur de référence, et de libérer les objets une fois qu'ils ne sont plus utilisés.

+ +

L'interface nsISupports

+ +
class Sample: public nsISupports{
+  private:
+    nsrefcnt mRefCnt;
+  public:
+    Sample();
+    virtual ~Sample();
+    NS_IMETHOD QueryInterface(const nsIID &aIID, void **aResult);
+    NS_IMETHOD_(nsrefcnt) AddRef(void);
+    NS_IMETHOD_(nsrefcnt) Release(void);
+};
+
+ +

Les différents types utilisés de l'l'interface sont décrites dans la section Types XPCOM. La mise en œuvre complète de nsISupports est indiquée ci-dessous. Voir Une implémentation de référence de QueryInterface pour des informations détaillées.

+ +

Mise en œuvre de l'interface nsISupports

+ +
// Initialiser le compteur de référence à 0
+Sample::Sample() : mRefCnt(0){
+}
+Sample::~Sample(){
+}
+// la mise en œuvre générique de QI
+NS_IMETHODIMP Sample::QueryInterface(const nsIID &aIID,
+                                  void **aResult){
+  if (!aResult) {
+    return NS_ERROR_NULL_POINTER;
+  }
+  *aResult = NULL;
+  if (aIID.Equals(kISupportsIID)) {
+    *aResult = (void *) this;
+  }
+  if (!*aResult) {
+    return NS_ERROR_NO_INTERFACE;
+  }
+  // ajoute une reference
+  AddRef();
+  return NS_OK;
+}
+NS_IMETHODIMP_(nsrefcnt) Sample::AddRef(){
+  return ++mRefCnt;
+}
+NS_IMETHODIMP_(nsrefcnt) Sample::Release(){
+  if (--mRefCnt == 0) {
+    delete this;
+    return 0;
+  }
+  // optional: retourn le nombre de reference
+  return mRefCnt;
+}
+
+ +

Object Interface Discovery

+ +

Héritage est un autre sujet très important dans la programmation orientée objet. L'héritage est le moyen par lequel une classe est dérivée d'une autre. Quand une classe hérite d'une autre classe, la classe hérite peut remplacer les comportements par défaut de la classe de base sans avoir à copier tout le code de cette classe et créer ainsi une classe plus spécifique, comme dans l'exemple suivant:

+ +

Héritage de classe simple

+ +
class Shape{
+  private:
+    int m_x;
+    int m_y;
+  public:
+    virtual void Draw() = 0;
+    Shape();
+    virtual ~Shape();
+};
+class Circle : public Shape{
+  private:
+    int m_radius;
+  public:
+    virtual Draw();
+    Circle(int x, int y, int radius);
+    virtual ~Circle();
+};
+
+ +

Circle(cercle) est une classe dérivée de Shape(forme) . Un cercle est une forme , en d'autres termes, mais une forme n'est pas nécessairement un cercle . Dans ce cas, forme est la classe de base et cercle est une sous-classe de forme .

+ +

Avec XPCOM, toutes les classes dérivent de l'interface nsISupports, de sorte que tous les objets héritent de nsISupports. Avec Héritage Class simple , par exemple, vous êtes en mesure de savoir si la forme est un cercle et dans ce cas de l'utiliser comme un cercle. Ces à quoi la caractéristique QueryInterface de nsISupports est destinée: elle permet aux utilisateurs de trouver et d'accéder aux différentes interfaces en fonction de leurs besoins.

+ +

En C++, vous pouvez utiliser une fonctionnalité assez avancé connu sous le nom de dynamic_cast<> , qui lève une exception si l'objet forme n'est un cercle . Mais les exceptions levants RTTI(Run-time type information) ne sont pas une option en raison de la lourdeur et de la compatibilité sur de nombreuses plates-formes, XPCOM fait les choses différemment.

+ +
+

Exceptions avec XPCOM

+ +

Les exceptions C++ ne sont pas pris en charge directement par XPCOM. Les exceptions doivent être manipulés dans le composant XPCOM, avant de franchir les frontières de l'interface. Toutes les méthodes de l'interface doivent retourner une valeur d'erreur nsresult (voir référence de l'API XPCOM pour une liste de ces codes d'erreur). Ces résultats de code d'erreur deviennent les «exceptions» que gère XPCOM.

+
+ +

Au lieu de tirer parti de RTTI du C++, XPCOM utilise la méthode QueryInterface qui passe l'objet à la bonne interface, si cette interface est pris en charge.

+ +

Chaque interface est pourvu d'un identifiant qui est généré à partir d'un outil nommée "uuidgen". Cet identifiant universel unique (UUID) est un numéro unique de 128 bits appelé IID. Ce n'est pas la même chose que l'ID d'un composant.

+ +

Quand un client veut découvrir si un objet prend en charge une interface donnée, le client passe l'IID assignée à cette interface dans la méthode QueryInterface de cet objet. Si l'objet prend en charge l'interface demandée, il ajoute une référence à lui-même et repasse un pointeur sur cette interface. Si l'objet ne prend pas en charge l'interface une erreur est renvoyée.

+ +
class nsISupports {
+  public:
+    long QueryInterface(const nsIID & uuid,
+                        void **result) = 0;
+    long AddRef(void) = 0;
+    long Release(void) = 0;
+};
+
+ +

Le premier paramètre de QueryInterface est une référence à une classe nommée nsIID , qui est une encapsulation de base de l'IID. Parmi les trois méthodes sur de la classe nsIID, Equals ,Parse et ToString , Equal est de loin le plus important, car elle est utilisé pour comparer deux nsIID dans le processus d'interrogation d'interface.

+ +

Lorsque vous implémentez la classe nsISupports (et vous le verrez dans le chapitre Utilitaires XPCOM pour faciliter les choses comment les macros peuvent rendre ce processus beaucoup plus facile), vous devez vous assurer que les méthodes de la classe renvoient un résultat valable lorsque le client appelle QueryInterface avec le nsISupports IID. QueryInterface devrait soutenir toutes les interfaces que le composant soutient.

+ +

Dans les implémentations de QueryInterface, l'argument IID est comparer à la classe nsIID. Si il y a une corespondence, l'objet this pointeur est converti en void, le compteur de référence est incrémenté, et l'interface renvoyée à l'appelant. Si il n'y a pas de correspondance, la classe retourne une erreur et la valeur de sortie est null .

+ +

Dans l'exemple ci-dessus, il est assez facile d'utiliser un C-style cast. Mais le casting peut devenir plus compliqué et vous devez d'abord passer void avec le type demandé, parce que vous devez retourner le pointeur d'interface dans la table virtuelle(vtable) correspondant à l'interface demandée. Castings peut devenir un problème quand il y a une hiérarchie d'héritage ambigu.

+ +

Identifiants XPCOM

+ +

En plus de l'identifiant d'interface IID discuté dans la section précédente, XPCOM utilise deux autres identificateurs très important pour distinguer les classes et les composants.

+ +
+

Classes XPCOM Identifier

+ +

La classe nsIID est en fait un typedef de la classe nsID. Les autres typedefs de nsID , CID et IID, se réfèrent respectivement à des implémentations spécifiques d'une classe concrète et d'une interface spécifique.

+ +

La classe nsID fournit des méthodes comme Equals pour comparer les identificateurs dans le code. Voir identificateurs XPCOM pour plus d'information sur nsID.

+
+ +

CID

+ +

Un CID est un nombre de 128 bits qui identifie de manière unique une classe ou un composant de la même manière qu'un IID identifie de manière unique une interface. Le CID pour nsISupports ressemble à ceci:

+ +

00000000-0000-0000-C000-000000000046

+ +

La longueur d'un CID  peut être lourd à traiter dans le code, de sorte que très souvent, vous verrez #defines pour les CID et les autres identifiants utilisés, comme dans cet exemple:

+ +
#define SAMPLE_CID \
+{ 0x777f7150, 0x4a2b, 0x4301, \
+{ 0xad, 0x10, 0x5e, 0xab, 0x25, 0xb3, 0x22, 0xaa}}
+
+ +

Vous verrez utilisé aussi NS_DEFINE_CID. Cette macro déclare une constante avec la valeur du CID:

+ +
static NS_DEFINE_CID(kWebShellCID, NS_WEB_SHELL_CID);
+
+ +

Un CID est parfois aussi désigné comme un identificateur de classe . Si la classe à laquelle un CID se réfère a plus d'une interface, il garanties que la classe implémente cette ensemble d'interfaces quand elle est publiée ou fixée.

+ +

Contrat ID

+ +

Un contract ID est une chaîne lisible utilisé pour accéder à un composant. Un CID ou un contract ID peuvent être utilisés pour accéder à un composant dans gestionnaire de composant. Le contract ID est utilisé pour le composant LDAP Opération :

+ +
"@mozilla.org/network/ldap-operation;1"
+
+ +

Le format du contract ID est formé du domaine, du module, du nom du composant séparés par des barres obliques et du numéro de version.

+ +

Comme un CID, un contract ID se réfère à une mise en œuvre plutôt qu'à une interface à l'instar IID. Mais un contract ID n'est pas liée à une mise en œuvre spécifique, contrairement au CID, il est donc plus général. Au lieu de cela, un contract ID spécifie seulement un ensemble donné d'interfaces qu'il met en œuvre, et un certain nombre de CID diffèrent peuvent intervenir en complément. Cette différence entre un contract ID et un CID est ce qui rend possible de remplacer des composants.

+ +

Utilisation

+ +

Une fois que le code est divisé en composants, le code client utilise habituellement l'opérateur new pour instancier des objets:

+ +
SomeClass* component = new SomeClass();
+
+ +

Ce modèle exige que le client connaisse le composant. Le factory design pattern peut être utilisé pour encapsuler la construction de l'objet. L'objectif du procédé est de créer un objet sans exposer les clients à la mise en œuvre et l'initialisation de cet objet. Dans l'exemple SomeClass, la construction et l'initialisation de SomeClass , qui implémente la classe abstraite SomeInterface, est contenu par la fonction New_SomeInterface:

+ +

Encapsuler le constructeur

+ +
int New_SomeInterface(SomeInterface** ret){
+  // Créer l'objet
+  SomeClass* out = new SomeClass();
+  if (!out) return -1;
+  // Initialisation de l'objet
+  if (out->Init() == FALSE){
+    delete out;
+    return -1;
+  }
+  // conversion de types de l'interface
+  *ret = static_cast<SomeInterface*>(out);
+  return 0;
+}
+
+ +

Factory est la classe qui gère effectivement la création des instances distinctes d'un composant. Dans XPCOM, les factories sont mises en œuvre par l'interface nsIFactory. Le modèle de conception utilise l'abstraction et encapsulalion de la construction et de l'initialisation de l'objet.

+ +

L'exemple de l'encapsulation du constructeur est une version simple et sans état ​​de factories, mais la programmation réel est généralement plus compliquée, ou les factories ont besoin de stocker l'état. Au minimum, la factory a besoin de préserver l'information des objets qu'elle a créée. Quand une factory gère les instances d'une classe construite dans une bibliothèque dynamique partagée, par exemple, elle doit savoir quand elle peut décharger la bibliothèque. Quand la factory conserve l'état, vous pouvez demander si il y a des références et savoir si la factory a créé des objets.

+ +

Un autre état ​​utile est de savoir si oui ou non un objet est un singleton . Par exemple, si la factory crée un objet qui est censé être un singleton, les appels suivants doivent retourner le même objet. Bien qu'il existe des outils et de meilleures façons de gérer les singletons (dont nous parlerons lorsque nous parlons de l'nsIServiceManager), un développeur peut vouloir utiliser cette information pour s'assurer que seul un objet singleton peut exister quelque soit l'usage.

+ +

Les exigences d'une classe factory peuvent être traitées de manière strictement fonctionnel, l'état étant détenu par des variables globales, mais il y a des avantages à utiliser des classes pour les factory. Lorsque vous utilisez une classe pour implémenter la fonctionnalité d'une factory, par exemple, vous utilisez nsISupports, qui vous permet de gérer la durée de vie de l'objets lui-mêmes. Ceci est important quand vous voulez regrouper des ensembles de factories et déterminer si elles peuvent être déchargées. Un autre avantage de l'utilisation de nsISupports est que vous pouvez supporter d'autres interfaces comme ils sont introduits. Comme nous allons le montrer lorsque nous aborderons nsIClassInfo, certaines factories soutiennent l'interrogation des informations sur la mise en œuvre sous-jacente, comme le langage d'écriture de l'objet dans les interfaces que l'objet prend en charge, etc. Ce genre d' "évolutivité" est un avantage clé qui est dérivé de nsISupports.

+ +

XPIDL et bibliothèques de types

+ +

Un moyen facile et puissant pour définir une interface - les interfaces dans un environnement de développement multi-plateforme, doit être indépendant du langage - est d'utiliser une interface définition langage(IDL). XPCOM utilise sa propre variante de la définition CORBA OMG Interface Langage (IDL) appelé XPIDL, qui vous permet de spécifier les méthodes, les attributs et les constantes d'une interface donnée, et aussi d'en définir héritage.

+ +

Il y a quelques inconvénients à la définition de votre interface à l'aide XPIDL. Il n'y a pas d'héritage multiple possible. Si vous définissez une nouvelle interface, il ne peut pas provenir de plus d'une interface. Une autre limitation des interfaces dans XPIDL est que les noms de méthode doivent être uniques. Vous ne pouvez pas avoir deux méthodes avec le même nom qui prennent des paramètres différents, et la solution de contournement - avec plusieurs noms de fonction - n'est pas joli:

+ +
void FooWithInt(in int x);
+void FooWithString(in string x);
+void FooWithURI(in nsIURI x);
+
+ +

Cependant, ces lacunes sont peu de chose en comparaison des fonctionnalités acquises en utilisant XPIDL. XPIDL vous permet de générer des bibliothèques de types , ou typelibs, qui sont des fichiers avec l'extension .xpt. La bibliothèque de types est une représentation binaire d'une ou plusieurs interfaces. Elle fournit un contrôle programmatique et l'accès à l'interface, ce qui est crucial pour les interfaces utilisées d'autre langages que C++. Lorsque les composants sont accessibles à partir d'autres langages, car ils peuvent être en XPCOM, ils utilisent la bibliothèque de type binaire pour accéder à l'interface, trouver les méthodes supportées, et les appeler. Cet aspect de XPCOM est appelé XPConnect . XPConnect est la couche de XPCOM qui donne accès à des composants XPCOM à partir des langages tels que JavaScript. Voir connexion à des composants de l'interface pour plus d'informations à propos de XPConnect.

+ +

Quand un composant est accessible à partir d'une langage autre que C ++, tels que JavaScript, son interface est dit "réfléchi" dans cette langage. Chaque interface réfléchie doit avoir une bibliothèque de type correspondant. Actuellement, vous pouvez écrire des composants en C, C++ ou JavaScript (et parfois Python ou Java, en fonction de l'état des liaisons respectives), et il y a des efforts en cours pour renforcer les liaisons XPCOM pour Ruby et Perl.

+ +
+

Écriture dans d'autres langages

+ +
+

Bien que vous ne disposez pas de l'accès à certains des outils que XPCOM prévoit pour C++ (comme les macros, les modèles, des pointeurs intelligents, et autres) lorsque vous créez des composants dans d'autres langages, vous pouvez être tellement à l'aise avec, que vous pouvez éviter complètement le C++ et construire, par exemple, les composants XPCOM en Python qui peuvent être utilisés à partir de JavaScript, ou vice versa.

+ +

Voir les Ressources pour plus d'informations à propos de Python et d'autres langages utilisables avec XPCOM.

+
+ +

Toutes les interfaces publiques en XPCOM sont définies en utilisant la syntaxe de XPIDL. Les bibliothèques de types et les fichiers d'en-tête de C++ sont générés à partir de ces fichiers IDL, et l'outil qui génére ces fichiers est appelé le compilateur xpidl . La section Définir l'interface de WEBLOCK dans XPIDL décrit la syntaxe de XPIDL en détail.

+ +

Services de XPCOM

+ +

Lorsque les clients utilisent des composants, ils instancient généralement un nouvel objet à chaque fois qu'ils ont besoin de la fonctionnalité du composant fournit. Tel est le cas lorsque, par exemple, les clients travaillent avec des fichiers: chaque fichier séparé est représenté par un objet différent, et plusieurs objets de fichier peut être utilisé à tout moment.

+ +

Mais il y a aussi une sorte d'objet connu comme le service , dont il n'y a toujours qu'une seule copie (même si il peut y avoir de nombreux services en cours d'exécution à un moment donné).Chaque fois qu'un client veut accéder à la fonctionnalité fournie par un service, ils parlent à la même instance de ce service. Quand un utilisateur recherche un numéro de téléphone dans une base de données de l'entreprise, par exemple, probablement cette base de données est représentée par un «objet» qui est le même pour tous les collaborateurs. Si ce n'etait pas le cas, l'application aurait besoin de garder deux copies d'une grande base de données en mémoire, pour la même chose, et il pourrait aussi y avoir des incohérences entre les documents si les copies ont divergé.

+ +

La fourniture de ce point d'accès unique à la fonctionnalité est mis en oeuvre par le singleton design pattern.

+ +

Dans XPCOM, en plus de l'appui et de la gestion des composants, il y a un certain nombre de services qui aident les développeurs à l'écriture de composants. Ces services incluent un fichier abstrait multiplateforme qui offre un accès uniforme et puissant pour les fichiers, les services d'annuaire qui maintiennent l'emplacement application, gestion de la mémoire pour s'assurer que tout le monde utilise le même allocateur de mémoire, et un système de notification d'événement qui permet de passer des messages simples. Le tutoriel va vous montrer l'utilisation de chacun de ces composants et services, et de la Référence de l'API XPCOM avec une liste d'interface complète.

+ +

Types XPCOM

+ +

Il existe de nombreux types déclarés et de simples macros que nous allons utiliser dans les exemples suivants. La plupart de ces types sont des applications simples. Les types les plus courants sont décrits dans les sections suivantes.

+ +

les types de méthode

+ +

Ce qui suit est un ensemble de types qui veillent à la convention d'appel correcte et de type de méthodes XPCOM de retour.

+
+ + + + + + + + + + + + + + + + + + + + + + + + +
NS_IMETHODType de retour de déclaration de méthode.
NS_IMETHODIMPType de retour de mise en œuvre de méthode. 
NS_IMETHODIMP_(type)Cas particulier de type de retour de mise en œuvre. Certaines méthodes telles que AddRef et Release ne renvoient pas le type de retour par défaut.
NS_IMPORTForce la résolution de la méthode en interne par la bibliothèque partagée.
NS_EXPORTForce l'exportation de la méthode par la bibliothèque partagée.
+ +

Référence Comptage

+ +

Ces macros gérer comptage de référence.

+ + + + + + + + + + + + + + + + + + + + +
NS_ADDREFAppelle AddRef de nsISupports.
NS_IF_ADDREFVérifie l'etat null avant d'appeler AddRef.
NS_RELEASEAppelle Release de nsISupports.
NS_IF_RELEASEVérifie l'etat null avant d'appeler Release.
+ +

Codes d'état

+ +

Ces macros testent les codes d'état.

+ + + + + + + + + + + + +
NS_FAILEDRetourne vrai si le code d'état passé est un échec
NS_SUCCEEDEDRetourne vrai est le code d'état passé est un succès.
+ +

Variable Mappings

+ + + + + + + + + + + + + + + + +
nsrefcntType de comptage de référence(entier de 32 bits).
nsresultType d'erreur par défaut(entier de 32 bits).
nsnullValeur null par défaut.
+ +

Codes d'erreur XPCOM communes

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NS_ERROR_NOT_INITIALIZEDInstance non initialisée.
NS_ERROR_ALREADY_INITIALIZEDInstance déjà initialisée.
NS_ERROR_NOT_IMPLEMENTEDMéthode non implémentée
NS_ERROR_NO_INTERFACEInterface non pris en charge.
NS_ERROR_NULL_POINTERPointeur valide nsnull.
NS_ERROR_FAILURELa méthode a échoué. Erreur générique.
NS_ERROR_UNEXPECTEDErreur inattendue.
NS_ERROR_OUT_OF_MEMORYAllocation de mémoire échouée.
NS_ERROR_FACTORY_NOT_REGISTEREDClasse inconnue du registre.
+ +

+

« PrécédentSuivant »

+

diff --git a/files/fr/mozilla/tech/xpcom/guide/creating_components/index.html b/files/fr/mozilla/tech/xpcom/guide/creating_components/index.html new file mode 100644 index 0000000000..dbffe93c6e --- /dev/null +++ b/files/fr/mozilla/tech/xpcom/guide/creating_components/index.html @@ -0,0 +1,281 @@ +--- +title: Créer des composants XPCOM +slug: Mozilla/Tech/XPCOM/Guide/Creating_components +translation_of: Mozilla/Tech/XPCOM/Guide/Creating_components +--- +

+

Suivant »

+

+ +

Ce guide a pour but de vous initier à Gecko, et de vous permettre de créer des composants XPCOM pour les applications Gecko. Bien que le principal objectif soit de vous permettre d'inclure du code C++ dans des composants utilisables dans Gecko, nous espérons pouvoir vous présenter tous les outils, techniques, et technologies qui constituent XPCOM. En conséquence, ce livre est agencé de telle sorte que vous puissiez suivre et créer vos propres composants ou en apprendre davantage sur les différents sujets XPCOM individuellement, comme un ouvrage de référence. Par exemple, l'introduction inclue une analyse des composants, et le premier chapitre - dans lequel vous compilerez le code de base et vous l'enregistrerez avec Mozilla - explique la relation entre les composants et les modules, les interfaces XPCOM, et le processus d'enregistrement de manière générale.

+ +
+

Remarque: De manière générale, essayez d'éviter de créer des composants XPCOM. Les add-ons devraient utiliser le nouveau Add-on SDK autant que possible ; cependant, il est probable que dans certains cas cela soit inévitable.

+
+ +
+

Remarque : Cet article décrit une méthode qui utilise xpidl mais vous devriez plutôt utiliser webidl.

+
+ +

Preface

+ +
+
Pour qui est ce tutoriel
+
Organisation du tutoriel
+
En Pratique
+
Conventions
+
Remerciements
+
+ +

Un aperçu de XPCOM

+ +
+
Solutions XPCOM
+
Gecko
+
Composants
+
Interfaces +
+
Interfaces et Encapsulation
+
L'interface de base nsISupports
+
+
+
XPCOM Identifiers +
+
CID
+
Contract ID
+
+
+
Factories +
+
XPIDL et bibliothèques de types
+
+
+
XPCOM Services
+
XPCOM Types +
+
Method Types
+
Reference Counting
+
Status Codes
+
Variable Mappings
+
Codes d'erreur XPCOM
+
+
+
+ +

Utilisation des composants XPCOM

+ +
+
Exemples de composants + +
+
gestionnaire de cookies
+
WebBrowserFind
+
WebLock
+
+
+
Utilisation de composant dans Mozilla +
+
Trouver des composants Mozilla
+
Utilisation de composants XPCOM dans votre Cpp
+
XPConnect: Utilisation de XPCOM avec un Script
+
+
+
+ +

Composants Internes

+ +
+
Creation de composants dans  Cpp
+
XPCOM Initialization +
+
XPCOM Registry Manifests
+
Registration Methods in XPCOM
+
Autoregistration
+
The Shutdown Process
+
Three Parts of a XPCOM Component Library
+
+
+
XPCOM Glue +
+
The Glue Library
+
XPCOM String Classes
+
+
+
+ +

Creating the Component Code

+ +
+
What We'll Be Working On
+
Component Registration +
+
The regxpcom Program
+
Registration Alternatives
+
+
+
Overview of the WebLock Module Source
+
Digging In: Required Includes and Constants +
+
Identifiers in XPCOM
+
Coding for the Registration Process
+
The Registration Methods
+
Creating an Instance of Your Component
+
+
+
webLock1.cpp
+
+ +

Using XPCOM Utilities to Make Things Easier

+ +
+
XPCOM Macros + +
+
Generic XPCOM Module Macros
+
Common Implementation Macros
+
Declaration Macros
+
+
+
webLock2.cpp
+
String Classes in XPCOM +
+
Using Strings
+
nsEmbedString and nsEmbedCString
+
+
+
Smart Pointers
+
+ +

Starting WebLock

+ +
+
Getting Called at Startup + +
+
Registering for Notifications
+
Getting Access to the Category Manager
+
+
+
Providing Access to WebLock
+
Creating the WebLock Programming Interface
+
Defining the WebLock Interface in XPIDL +
+
The XPIDL Syntax
+
Scriptable Interfaces
+
Subclassing nsISupports
+
The Web Locking Interface
+
+
+
Implementing WebLock +
+
Declaration Macros
+
Representing Return Values in XPCOM
+
XPIDL Code Generation
+
Getting the WebLock Service from a Client
+
Implementing the iWebLock Interface
+
The Directory Service
+
Modifying Paths with nsIFile
+
Manipulating Files with nsIFile
+
Using nsILocalFile for Reading Data
+
Processing the White List Data
+
+
+
iWebLock Method By Method +
+
Lock and Unlock
+
AddSite
+
RemoveSite
+
SetSites
+
GetNext
+
GetSites
+
HasMoreElements
+
+
+
+ +

Finishing the Component

+ +
+
Using Frozen Interfaces + +
+
Copying Interfaces Into Your Build Environment
+
Implementing the nsIContentPolicy Interface
+
Receiving Notifications
+
+
+
Implementing the nsIContentPolicy +
+
Uniform Resource Locators
+
Checking the White List
+
Creating nsIURI Objects
+
+
+
+ +

Building the WebLock UI

+ +
+
User Interface Package List
+
Client Code Overview
+
XUL +
+
The XUL Document
+
The Locking UI
+
Site Adding UI
+
weblock.xul
+
+
+
Overlaying New User Interface Into Mozilla +
+
webLockOverlay.xul
+
+
+
Other Resources +
+
weblock.css
+
Image Resources
+
+
+
+ +

Packaging WebLock

+ +
+
Component Installation Overview
+
Archiving Resources
+
The WebLock Installation Script
+
The WebLock Trigger Script
+
Distributing Your Component
+
+ +

Appendix A - Setting up the Gecko SDK

+ +
+
Downloading and Setting the SDK
+
Building a Microsoft Visual Cpp Project +
+
Creating a New Project
+
Adding the Gecko SDK to the Project Settings
+
+
+
Building a Windows Project
+
A Makefile for Unix
+
+ +

Appendix B - Resources

+ +
+
WebLock Resources
+
Gecko Resources
+
XPCOM Resources
+
General Development Resources
+
+ +

+

Suivant »

+

+

Copyright (c) 2003 by Doug Turner and Ian Oeschger. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.02 or later. Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

+

+ +

diff --git a/files/fr/mozilla/tech/xpcom/guide/creating_components/preface/index.html b/files/fr/mozilla/tech/xpcom/guide/creating_components/preface/index.html new file mode 100644 index 0000000000..478a139e2f --- /dev/null +++ b/files/fr/mozilla/tech/xpcom/guide/creating_components/preface/index.html @@ -0,0 +1,77 @@ +--- +title: Préface +slug: Mozilla/Tech/XPCOM/Guide/Creating_components/Preface +tags: + - Guide + - XPCOM +translation_of: Mozilla/Tech/XPCOM/Guide/Creating_components/Preface +--- +

+

Suivant »

+

+ +

Cette section concerne Gecko et la création de composants XPCOM pour des applications basées sur Gecko. Bien que l'accent soit mis sur les mesures concrètes que vous prenez pour créer un code C ++ valide dans un composant qui peut être utilisé dans Gecko, nous espérons que ces mesures nous donneront également l'occasion de discuter de tous les outils, les techniques et les technologies qui composent XPCOM. En conséquence, le livre est agencé de telle sorte que vous puissiez suivre et créer vos propres composants et en apprendre davantage sur XPCOM, comme dans un ouvrage de référence. Par exemple, l'introduction comprend une discussion sur les composants, et le premier chapitre - dans laquelle vous compilez le code de base et l'enregistrer avec Mozilla - éclair sur la relation entre les composants et les modules, les interfaces XPCOM et le processus d'enregistrement en général.

+ +

Le début de chaque chapitre fournit une liste des principaux sujets abordés. Des barres latérales sont incluses pour mettre en évidence les détails techniques. À la fin du livre, vous aurez appris comment construire un composant XPCOM et vous comprendrez sont fonctionnement dans Gecko.

+ +

Pour qui est ce tutoriel ?

+ +

La Création de composants XPCOM est destinée aux développeurs C ++. Bien que vous pouvez créer des composants XPCOM en JavaScript ou d'autres langages, le code de mise en œuvre des composants est écrit en C ++, et une grande partie de la discussion sur la façon de programmer un composant XPCOM utilise le C ++. Vous ne devez pas non plus être un expert C ++. Bien que les idées de base telles que l'héritage et l'encapsulation devraient vous être familiers. Leur utilisation est expliquée à chaque fois dans le tutoriel. En outre, beaucoup d'exemples sont en JavaScript,  utilisé dans Mozilla pour accéder aux composants XPCOM comme des objets scriptable, votre familiarité avec ce langage est également utile.

+ +

XPCOM pour Cross Platform Component Object Model est similaire à Microsoft COM. Si vous avez une expérience avec ces technologies, beaucoup d'entre elles peuvent être appliquées à XPCOM. Cependant, ce tutoriel ne suppose aucune connaissance préalable du COM - toutes les idées de base seront présentés.

+ +

Ce livre fournit un tutoriel sur la construction d'un composant XPCOM contrôlant le comportement d'un navigateur. Bien que XPCOM peux être utilisé dans de nombreux environnements qui sont sans rapport avec la navigation web, le principal client de XPCOM est Gecko. Il est open source, conforme aux standards, possède un navigateur Web embarquable, où il est plus facile et plus pratique d'illustrer les fonctionnalités d'XPCOM. Une description complète de ce composant peut être trouvé dans le chapitre ce que nous allons faire du didacticiel.

+ +
+

Malgré ce que dit le vieux document, XPCOM ne devrait pas être utilisé pour faire des plugins NPAPI scriptable. A partir de Gecko 1.7.5 (Firefox 1.0) une extension spéciale NPAPI pour scriptabilité est prise en charge, voir plugins Scripting.

+
+ +

Organisation du Tutoriel

+ +

La liste suivante donne un aperçu des étapes que nous allons suivre pour construire un composant XPCOM appelé WebLock, qui prévoit une fonctionnalité de blocage de sites pour les navigateurs basés sur Gecko. Chacune de ces étapes a son propre chapitre, dans lequel un certain nombre de sujets liés à l'étape sont abordés.

+ + + +

Continuons avec des exemples

+ +

Il y a deux façons d'installer XPCOM sur votre machine pour que vous puissiez commencer à créer des composants. Si vous avez déjà Mozilla build ou le code source de Mozilla 1.2 ou ultérieure, vous pouvez utiliser le framework XPCOM disponible. Si non, la façon la plus simple d'obtenir et d'utiliser XPCOM est de télécharger le SDK Gecko, qui est un ensemble de bibliothèques et d'outils qui comporte le framework XPCOM.

+ +

Que vous compiliez le code source ou utilisiez le SDK Gecko, vous pouvez construire vos propres composants en utilisant les composants existant dans Gecko. Le composant WebLock que nous décrirons dans ce tutoriel met ceci en pratique (et, nous l'espérons, de façon utile) en plus de la manipulation du navigateur. Pour que cela fonctionne, votre code source SDK Gecko ou Mozilla doit être de version 1.2 ou ultérieure (l'interface XPCOM n'a pas été entièrement fixée dans les versions antérieures).

+ +

Ce livre suppose que vous utilisez SDK plutôt que de compiler le code source de Mozilla, bien que la différence entre ces deux approches soit minime. La construction, et l'obtention de l'accès à la programmation de composants Gecko est fournies en annexe à ce livre, Configuration du SDK Gecko .

+ +

Conventions

+ +

Les conventions de formats ci-dessous sont utilisées pour désigner des types d'informations spécifiques dans le livre et rendre les choses plus faciles à analyser. Le but est d'utiliser aussi peu de formats que possible, mais de distinguer clairement les différents types d'informations.

+ + + + + + + + + + + + + + + + + + + + + + + + +
FormatDescription
grasnoms des composants apparaissent en gras dans le texte
monospacelignes de code , noms d'interface et membres d'interfaces (par exemple, createInstance()) apparaissent avec cette police. Les lignes de code sont placées dans des encarts séparés. En outre, les noms de fichiers et de répertoires possèdent également cette police.
italiqueles variables apparaissent en italique. Les termes importants et les nouveaux concepts sont également en italique la première fois qu'ils apparaissent dans le texte. Ces termes sont expliqués soit immédiatement après leur citation, ou bien le lecteur est renvoyé à une section dans le livre où ils sont décrits en détail.
lienRéférences à d'autres sections, figures ou tableaux et leur liens vers ces articles.
diff --git a/files/fr/mozilla/tech/xpcom/guide/creating_components/using_xpcom_components/index.html b/files/fr/mozilla/tech/xpcom/guide/creating_components/using_xpcom_components/index.html new file mode 100644 index 0000000000..3a6b536ee6 --- /dev/null +++ b/files/fr/mozilla/tech/xpcom/guide/creating_components/using_xpcom_components/index.html @@ -0,0 +1,303 @@ +--- +title: Utilisation des composants XPCOM +slug: Mozilla/Tech/XPCOM/Guide/Creating_components/Using_XPCOM_Components +translation_of: Mozilla/Tech/XPCOM/Guide/Creating_components/Using_XPCOM_Components +--- +

+

« PrécédentSuivant »

+
Une des meilleures façons de commencer à travailler avec XPCOM - surtout quand vous concevez l'interface d'un composant qui sera utilisé par d'autres(WebLock) - est de regarder comment les clients utilisent déjà des composants XPCOM.

+ +

Les applications sophistiqués comme le navigateur Mozilla sont des utilisateurs de modules XPCOM. En fait, la quasi-totalité des fonctionnalités associees au navigateur - la navigation, la gestion des fenêtres, la gestion des cookies, les signets, la sécurité, la recherche, de rendu et d'autres caractéristiques - sont définies par des composants XPCOM et consultée par le biais de leurs interfaces. Mozilla est fait de composants XPCOM.

+ +

Ce chapitre montre comment Mozilla utilise certains de ces objets XPCOM, tels que le CookieManager, et explique comment l'accès au composant de Weblock sera défini.

+ +

Exemples de composants

+ +

Pour en savoir plus sur l'utilisation de composant particulier référez vous à API XPCOM référence . Pour l'instant, ili est important de comprendre comment un composant est  utilisé par le navigateur Mozilla.

+ +

Gestionnaire de Cookies

+ +

Gestion des cookies est l'une des nombreux fonctionnalités qui est mise disposition du navigateur sous la forme de composant XPCOM et qui peut être réutilisé par les développeurs qui veulent des fonctionnalités similaires dans leurs applications. Chaque fois qu'un utilisateur accède à la boîte de dialogue de Cookie Manager pour afficher, organiser, ou supprimer les cookies qui ont été stockées sur le système, ils utilisent le composant CookieManager en coulisses. La boite de dialogue du gestionnaire de cookies montre interface utilisateur qui est présenté à l'utilisateur dans Mozilla pour l'utilisation du composant CookieManager.

+ +

Boite de dialogue du gestionnaire de cookies

+ +

Image:cookie_mgr_dlog.png

+ +

Cette boite de dialogue est écrit en XUL et en JavaScript, et utilise une partie de XPCOM appelé XPConnect pour se connecter de manière transparente au composant CookieManager (voir Connexion à des interfaces de composants ci-dessous). XUL expose les fonctionnalités du composant CookieManager, il est tres utilisé dans l'environement Mozilla.

+ +

La fonctionnalité du composant CookieManager est disponible à travers l'interface nsICookieManager, ses méthodes publiques sont exposées dans le tableau ci-dessous.

+ +

Interface nsICookieManager

+ + + + + + + + + + + + + + + + +
removeAllRetirez tous les cookies de la liste des cookies.
enumeratorÉnumérer la liste des cookies.
removeRetirer un cookie particulier de la liste.
+ +

Linterface XPCOM garanti la stabilitée, même si il y a des changements sous-jacentes. Les interfaces sont publics et les implémentations sont privés. Lorsque l'utilisateur sélectionne l'un des cookies affichés dans la liste, puis clique sur le bouton Supprimer, la méthode Remove de nsICookieManager est appelée. La fonction est réalisée par le composant CookieManager, et le cookie sélectionné est supprimé du disque et retiré de la liste affichée.

+ +

L'extrait Utiliser le composant CookieManager en JavaScript montre comment Remove() peut être appelé à partir de JavaScript:

+ +

Utiliser le composant CookieManager en JavaScript

+ +
// xpconnect to cookiemanager
+// get the cookie manager component in JavaScript
+var cmgr = Components.classes["@mozilla.org/cookiemanager;1"]
+                     .getService();
+cmgr = cmgr.QueryInterface(Components.interfaces.nsICookieManager);
+
+// called as part of a largerDeleteAllCookies() function
+function FinalizeCookieDeletions() {
+  for (var c=0; c<deletedCookies.length; c++) {
+    cmgr.remove(deletedCookies[c].host,
+                deletedCookies[c].name,
+                deletedCookies[c].path);
+  }
+  deletedCookies.length = 0;
+}
+
+ +
+

Connexion à l'interface d'un composant

+ +
+

L'interface Mozilla utilise JavaScript pour accèder aux composants XPCOM par l'intermediaire de XPConnect.

+ +

XPConnect via XPIDL est appeler à partir d'objets JavaScript, qui représentent des instances de composants comme CookieManager.

+ +

XPConnect lie le code d'application de l'interface utilisateur du navigateur Mozilla(XUL basé sur Gecko), à l'environnement JavaScript(comme xpcshell)..

+
+ +

Les arrangements contractuels que permet XPCOM ouvre la voie à l'interopérabilité binaire, pour l'accès, l'utilisation et la réutilisation des composants XPCOM. Ils permettent d'utiliser des composants écrits dans d'autres langages tels que JavaScript, Python et autres.

+ +

Dans le navigateur Mozilla, les composants sont souvant utilisés à partir de JavaScript. En fait, une recherche du code source Mozilla révèle que le composant CookieManager est appelée seulement à partir de JavaScript. C'est ce que nous allons faire dans ce tutoriel.

+
+ +
+

JavaScript et Mozilla

+ +
+

JavaScript est la lingua franca du navigateur Mozilla, et les liaisons entre elle et XPCOM sont forts et bien définie. scriptabilité , cette capacité à obtenir et utiliser des composants XPCOM à partir de JavaScript et d'autres langages pour lesquels fixations XPConnect ont été créés, est une caractéristique essentielle de XPCOM.

+
+ +

Le composant WebBrowserFind

+ +

Les composants sont utilisés partout - dans les fonctionnalités du navigateur de haut niveau tels que nsWebBrowserFind , qui fournit les méthodes find() et findNext() pour trouver du contenu dans les pages Web, et dans les tâches de bas niveau tels que la manipulation des données.

+ +

En plus du composant CookieManager, le composant WebBrowserFind est une autre partie d'un grand ensemble d'interfaces du navigation Web que vous pouvez utiliser. Son interface nsIWebBrowserFind est présentée dans L'interface nsIWebBrowserFind .

+
+ +

Les méthodes de nsIWebBrowserFind

+ + + + + + + + + + + + + + + + + + + + + + + + +
findNextTrouver la prochaine occurrence de la chaîne recherchée.
findBackwardsAttribut booléen qui ajuste findNext() pour rechercher vers le début du document.
searchFramesAttribut booléen qui indique si la recherche s'efectue dans les sous-fenêtres du document actuel.
matchCaseAttribut booléen qui indique la sensibilité à la casse.
entireWordAttribut booléen qui indique si le mot entier doit correspondre.
+ +

Quand vous utilisez l'interface d'un composant, vous pouvez demander si il suportr d'autres interfaces. Ce service, qui est défini dans nsISupports est mis en œuvre par tous les composants XPCOM, vous permet d'interroger et de passer d'une interface à un composant dans le cadre des runtime object typing. Il est géré par QueryInterface, qui a été introduit dans le chapitre Vue d'ensemble du XPCOM . L'API de référence XPCOM fournit une référence complète des composants XPCOM disponibles dans Mozilla.

+ +

The WebLock Component

+ +

Now it's time to look at the WebLock component as another example of XPCOM components (since you'll be creating it shortly). In object-oriented programming, it's typical to design the interface first-to define the functionality that's going to be provided in the abstract, without worrying about how this functionality will be achieved. So we'll put aside the details of the implementation until the next chapter and look at the component from the outside-at the interface to the WebLock component.

+ +

The IWebLock Interface

+ + + + + + + + + + + + + + + + + + + + + + + + +
lockLock the browser to the current site (or to the whitelist of approved sites read from disk).
unlockUnlock the browser for unrestricted use.
addSiteAdd a new site to the whitelist.
removeSiteRemove a given site from the whitelist.
sitesEnumerator for the list of approved sites read in from the whitelist.
+ +

The WebLock component is software that implements all of these methods in the way described by the interface definition. It registers itself for use when the browser starts up, and provides a factory that creates an instance of it for use when the user or administrator clicks the weblock icon in the browser's user interface.

+ +

Component Use in Mozilla

+ +

So how are components obtained and used in Mozilla? You've seen some enticing snippets of JavaScript in earlier sections of this chapter, but we haven't explained how XPCOM makes components available in general.

+ +

This section discusses practical component use in Mozilla. It's divided into three subsections: one about actually finding all these binary components in Mozilla and two others corresponding to the two main ways that clients typically access XPCOM components:

+ +

Finding Mozilla Components

+ +

This book attempts to provide reference information for XPCOM components and their interfaces that are frozen as of the time of this writing. The Mozilla embedding project tracks the currently frozen interfaces.

+ +

Mozilla also has some tools that can find and display information about the interfaces available in Gecko such as the XPCOM Component Viewer, described below, and MXR, which is a web-based source code viewing tool.

+ +

The challenge to making good information about XPCOM components available to prospective clients, however, is that the process of freezing the interfaces that are implemented by these components is still ongoing. The Component Viewer does not distinguish between components that are frozen and those that are not. In the source code you view in MXR, interfaces that have been frozen are marked at the top with @status frozen.

+ +
The XPCOM Component Viewer
+ +

The XPCOM Component Viewer is an add-on you can install in your browser (in sandbox, not available for now).
+ Alternatively, you can try XPCOMViewer, a similar add-on.

+ +

XPCOM Component Viewer

+ +

Image:using-component-viewer.png

+ +

The left column shows the components - in this case a subset returned from a search on "gfx" as part of the contract ID and the right column a list of the interfaces. When you open a component on the left, you can see the interfaces it implements along with a list of the methods provided by each interface.

+ +

The XPCOM Component Viewer can be extremely useful for this sort of gross interrogation, but again: it displays all of the components and interfaces in your build, many of which are not practical for actual reuse or stable enough to be used reliably in your own application development. Use comprehensive lists like this with caution.

+ +

 

+ +

Using XPCOM Components in Your Cpp

+ +

XPConnect makes it easy to acecss XPCOM components as JavaScript objects, but using XPCOM components in C++ is not much more difficult.

+ +

Managing Cookies from Cpp duplicates code from Getting the CookieManager Component in JavaScript, but in C++ instead of JavaScript.

+ +

Managing Cookies from Cpp

+ +
nsCOMPtr<nsIServiceManager> servMan;
+nsresult rv = NS_GetServiceManager(getter_AddRefs(servMan));
+if (NS_FAILED(rv))
+  return -1;
+
+nsCOMPtr<nsICookieManager> cookieManager;
+rv = servMan->GetServiceByContractID("@mozilla.org/cookiemanager",
+                                     NS_GET_IID(nsICookieManager),
+                                     getter_AddRefs(cookieManager));
+
+if (NS_FAILED(rv))
+  return -1;
+
+PRUint32 len;
+deletedCookies->GetLength(&len);
+
+for (int c=0; c<len; c++)
+    cookieManager->Remove(deletedCookies[c].host,
+                          deletedCookies[c].name,
+                          deletedCookies[c].path,
+                          PR_FALSE);
+
+ +

XXX: In the original document, there were only the first three parameters to the |Remove| call. I added |PR_FALSE| as a fourth parameter because the interface seems to require it: http://lxr.mozilla.org/mozilla/source/netwerk/cookie/public/nsICookieManager.idl#64 This problem also appears in the JavaScript version below, and I've added |false| as a fourth parameter there as well.

+ +

If your application is written in C++, then Managing Cookies from Cpp shows the steps you take to get an XPCOM component, specify the interface on that component you want to use, and call methods on that interface.

+ +

XPConnect: Using XPCOM Components From Script

+ +

The CookieManager component we discussed at the beginning of this chapter provides a good opportunity to talk further about using components from JavaScript. In the following code fragment from the Cookie Manager dialog in Mozilla, you can see a singleton of the CookieManager component being created with the getService() method and used to provide the functionality that lets users load and remove cookies from the user interface.

+ +

Managing Cookies from JavaScript

+ +
var cmgr = Components.classes["@mozilla.org/cookiemanager;1"]
+                     .getService();
+cmgr = cmgr.QueryInterface(Components.interfaces.nsICookieManager);
+
+function loadCookies() {
+  // load cookies into a table
+  var enumerator = cmgr.enumerator;
+  var count = 0;
+  var showPolicyField = false;
+  while (enumerator.hasMoreElements()) {
+    var nextCookie = enumerator.getNext();
+    nextCookie = nextCookie.QueryInterface(Components.interfaces.nsICookie);
+    /* .... */
+}
+function FinalizeCookieDeletions() {
+  for (var c=0; c<deletedCookies.length; c++) {
+    cmgr.remove(deletedCookies[c].host,
+                deletedCookies[c].name,
+                deletedCookies[c].path,
+                false);
+  }
+  deletedCookies.length = 0;
+}
+
+ +

XXX: In the original document, there were only the first three parameters to the |remove| call. I added |false| as a fourth parameter because the interface seems to require it: http://lxr.mozilla.org/mozilla/source/netwerk/cookie/public/nsICookieManager.idl#64 This problem also appears in the C++ version above, and I've added |PR_FALSE| as a fourth parameter there as well.

+ +

Beyond the methods that are being called on the CookieManager itself (e.g., cookiemanager.remove, which maps to the remove() function in The nsICookieManager Interface), note the special XPConnect objects and methods that reflect the XPCOM component into JavaScript.

+ +

Components is the JavaScript object that controls the connection to components, and classes is an array of all of the classes you can ask for by contract ID. To instantiate an XPCOM component in JavaScript, you create a new Component object and pass in the contract ID for the component you want and ask for either a singleton or an instance of that component to be returned:

+ +
var cmgr = Components.classes["@mozilla.org/cookiemanager;1"]
+                     .getService();
+
+ +

The resulting cookiemanager object then provides access to all of the methods for that component that have been defined in IDL and compiled into the type library. Using the CookieManager component, you could write code like this to delete all cookies from the system:

+ +
cmgr = Components.classes["@mozilla.org/cookiemanager;1"]
+                 .getService();
+cmgr = cmgr.QueryInterface(Components.interfaces.nsICookieManager);
+
+// delete all cookies
+function trashEm() {
+   cmgr.removeAll();
+}
+
+ +

Another vital feature of the XPConnect glue this example shows is the availability of the QueryInterface method on all objects that are reflected into JavaScript from XPCOM. As in C++, you can use this method to ask for other interfaces that are available on the given object.

+ +
+

Services Versus Regular Instances

+ +

Whether to have clients use your component as an instance or a service is a design question, really, and something you should be clear about in the documentation for your component. Actually, the getService() method in the example here calls through to the createInstance() method that is also available from the Component object and caches the result, making it a singleton rather than a normal instance.

+ +

The singleton design pattern that is used to create services is described in XPCOM Services.

+
+ +

Remember, QueryInterface allows you to query an object for the interfaces it supports. In the case of the snippet in The nsICookieManager Interface, the QueryInterface method is being used to get the nsICookie interface from the enumerator so that, for instance, the JavaScript code can access the value and name attributes for each cookie.

+ +
    +
  1. Note : cookie-manager-ui
    Note that the interface is not part of the component itself. XPCOM makes it easy to use components like CookieManager from Mozilla's Cross Platform Front End (XPFE) and other user interfaces, but the component itself doesn't provide its own UI.
    2. +
  2. Note : private-xpcom-interfaces
    There are exceptions to this. Some XPCOM interfaces are also private and not made for general use. Private interfaces do not have the same requirements as the ones that are made available publicly in IDL.
    3. +
  3. Note : cookie-manager-in-tutorial
    The CookieManager component is used to persist for the web locking functionality described in this tutorial.
    4. +
+ +

+

« PrécédentSuivant »

+

+

Copyright (c) 2003 by Doug Turner and Ian Oeschger. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.02 or later. Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper) book form is prohibited unless prior permission is obtained from the copyright holder.

+

diff --git a/files/fr/mozilla/tech/xpcom/guide/index.html b/files/fr/mozilla/tech/xpcom/guide/index.html new file mode 100644 index 0000000000..748a2784b5 --- /dev/null +++ b/files/fr/mozilla/tech/xpcom/guide/index.html @@ -0,0 +1,16 @@ +--- +title: XPCOM guide +slug: Mozilla/Tech/XPCOM/Guide +tags: + - Landing + - Mozilla + - NeedsTranslation + - TopicStub + - XPCOM +translation_of: Mozilla/Tech/XPCOM/Guide +--- +

These articles provide tutorials and usage documentation for XPCOM, including how to use it in your own projects and how to build XPCOM components for your Firefox add-ons and the like.

+

+
Compiler un composant XPCOM javascript
Créer des composants XPCOM
Ce guide a pour but de vous initier à Gecko, et de vous permettre de créer des composants XPCOM pour les applications Gecko.
+
+

diff --git a/files/fr/mozilla/tech/xpidl/index.html b/files/fr/mozilla/tech/xpidl/index.html new file mode 100644 index 0000000000..6f7e3d2425 --- /dev/null +++ b/files/fr/mozilla/tech/xpidl/index.html @@ -0,0 +1,22 @@ +--- +title: XPIDL +slug: Mozilla/Tech/XPIDL +tags: + - XPCOM +translation_of: Mozilla/Tech/XPIDL +--- +

XPIDL est un langage de description d'interfaces utilisé pour spécifier les classes de l'interface XPCOM.

+

Les langages de description d'interfaces (IDL) sont utilisés pour décrire des interfaces d'une manière indépendante d'un langage et d'une machine. Les IDL permettent de définir des interfaces qui peuvent alors être employées par des outils pour générer automatiquement des spécifications d'interfaces propres à un langage donné.

+

Un de ces outils est xpidl, utilisé pour générer des fichiers d'en-têtes C++, des informations typelib et plusieurs autres choses.

+

Écriture de fichiers interface XPIDL

+

XPIDL ressemble fortement à OMG IDL avec une syntaxe étendue pour traiter les IID et des types supplémentaires. Quelques exemples sont disponibles dans les répertoires xpcom/base et xpcom/ds des sources de Mozilla.

+ +

Ressources

+ -- cgit v1.2.3-54-g00ecf