Comparar revisiones

Interior del Componente

Revisión 283017:

Revisión 283017 de Maharba el

Revisión 226396:

Revisión 226396 de Maharba el

Título:
Interior del Componente
Interior del Componente
Enlace amigable (slug):
Creación_de_Componentes_XPCOM/Interior_del_Componente
Creación_de_Componentes_XPCOM/Interior_del_Componente
Etiquetas:
XPCOM, Todas_las_Categorías
Contenido:

Revisión 283017
Revisión 226396
t7    <p>t
8      {{ PreviousNext("Creación de Componentes XPCOM:Using XPCOM 
>Components", "Creación de Componentes XPCOM:Creating the Componen 
>t Code") }} En el capítulo anterior describimos los componentes d 
>esde una perspectiva de un cliente de los componentes XPCOM, en e 
>ste capútulo abordamos los componentes desde la perspectiva del d 
>esarrollador del programa. Léelo para ver como se implementan gen 
>eralmente los componentes en XPCOM, o puedes brincarte al siguien 
>te capítulo, donde el tutorial del componente WebLock te lleva pa 
>so a paso através del proceso de creación del componente. <span c 
>lass="comment">XXX mediawiki...</span><span class="comment">XXX s 
>ucks</span> 
9    </p>
10    <h3 id="Creaci.C3.B3n_de_Componentes_en_C.2B.2B" name="Creaci
>.C3.B3n_de_Componentes_en_C.2B.2B"> 
11      Creación de Componentes en C++
12    </h3>
13    <p>
14      Empecemos por examinar como se escriben en C++ los componen
>tes XPCOM. El tipo más común de componente es el escrito en C++ y 
> compilado en una biblioteca compartida (una <abbr title="Dynamic 
> Link Library">DLL</abbr> en un sistema Windows o una <abbr title 
>="Dynamic Shared Object">DSO</abbr> en Unix). 
15    </p>
16    <p>
17      La imagen de abajo muestra la relación básica entre una bib
>lioteca que contiene la implementación del código del componente  
>que escribiste y la plataforma XPCOM en sí misma. En este diagram 
>a, la superficie más externa del módulo es la biblioteca comparti 
>da en la que se define un componente. 
18    </p>
19    <p>
20      {{ Block-title("Un Componente en la Plataforma XPCOM") }}
21    </p>
22    <p>
23      <img alt="Image:component-internals-framework.png" fileid="
>0" src="File:es/Media_Gallery/Component-internals-framework.png"> 
24    </p>
25    <p>
26      Cuando construyes un componente o un módulo y lo compilas d
>entro de una biblioteca, debe exportar un método llamado <code>NS 
>GetModule</code>. Esta función <code>NSGetModule</code> es el pun 
>to de acceso a la biblioteca. Es llamado durante el registro y el 
> desregistro del componente y cuando XPCOM quiere descubrir qué i 
>nterfaces o clases implementa el módulo/biblioteca. En este capít 
>ulo abordaremos todo este proceso. 
27    </p>
28    <p>
29      Como ilustra {{ Anch("Un Componente en la Plataforma XPCOM"
>) }}, además del punto de acceso <code>NSGetModule</code>, están  
>las interfaces <code>nsIModule</code> y <code>nsIFactory</code> q 
>ue controlan la creación actual del componente y también las part 
>es XPCOM glue y cadenas, que discutiremos un poco a detalle en la 
> siguiente sección (Ve <a href="es/Creaci%c3%b3n_de_Componentes_X 
>PCOM/Interior_del_Componente#XPCOM_Glue">XPCOM Glue</a>). Estas n 
>os darán utilidades para desarrollo fácil más adelante como son p 
>unteros inteligentes, soporte de módulos genéricos e implementaci 
>ones simples de cadenas. La parte más larga y posiblemente la más 
> compleja de un componente es el código específico del componente 
> en sí mismo. 
30    </p>
31    <div class="side-note">
32      <p>
33        {{ Block-title("¿Pero Dónde Están los Componentes?") }}
34      </p>
35      <p>
36        Los componentes residen en módulos y esos módulos son def
>inidos en bibliotecas compartidas típicamente situadas en el dire 
>ctorio <i>components</i> de una aplicación XPCOM. 
37      </p>
38      <p>
39        Un conjunto de bibliotecas son almacenadas por defecto en
> este directorio components es lo que hay en una típica instalaci 
>ón de Gecko, dando la funcionalidad que consiste en trabajo en re 
>d, layout, composición, una interfaz de usuario multiplataforma y 
> otros. 
40      </p>
41      <p>
42        Otra vista aún más básica de esta relación de componentes
> a archivos e interfaces que los definen se muestra en <a href="e 
>s/Creaci%c3%b3n_de_Componentes_XPCOM/Creaci%c3%b3n_del_C%c3%b3dig 
>o_del_Componente">Vista de Papel Cebolla de la creación del Compo 
>nente XPCOM</a> en el próximo capítulo. El componente es una abst 
>racción situada entre el módulo actual en el que se implementa y  
>los objetos que el código de su factoría crea para que uso de los 
> clientes. 
43      </p>
44    </div>
45    <h3 id="Inicializaci.C3.B3n_de_XPCOM" name="Inicializaci.C3.B
>3n_de_XPCOM"> 
46      Inicialización de XPCOM
47    </h3>
48    <p>
49      Para entender porqué y cuándo tu biblioteca de componentes 
>es llamada, es importante entender el proceso de inicialización d 
>e XPCOM. Cuando inicia una aplicación, la aplicación puede <i>ini 
>cializar</i> XPCOM. La secuencia de eventos que lanza esta inicia 
>lización de XPCOM pueden ser lanzados por una ccioón del usuario  
>o por el inicio de la aplicación en sí misma. Un buscador web que 
> tiene embebido Gecko, por ejemplo, puede inicializar XPCOM al in 
>icio atravéz de APIs embebidas. Otra aplicación puede este inicio 
> hasta que XPCOM se necesite por primera vez. En otro caso, la se 
>cuencia de inicialización dentro de XPCOM es la misma. 
50    </p>
51    <p>
52      XPCOM inicia cuando la aplicación hace una llamada para ini
>cializarlo. Los parámetros pasados a esta llamada de inicializaci 
>ón te permiten configurar algunos aspectos de XPCOM, incluyendo l 
>a personalización de la ubicación de directorios específicos. El  
>propósito principal del API en este punto es cambiar que director 
>io <i>components</i> inspecciona cuando busca componentes XPCOM.  
>Así es como se usa el API, por ejemplo, en el <i>Gecko Runtime En 
>vironment</i> (GRE). 
53    </p>
54    <div class="side-note">
55      <p>
56        {{ Block-title("Inicialización de XPCOM") }}
57      </p>
58      <p>
59        Los seis pasos básicos para arrancar XPCOM son los siguie
>ntes: 
60      </p>
61      <ol>
62        <li>La aplicación inicia XPCOM.
63        </li>
64        <li>XPCOM envía una notificación que inicia el arranque.
65        </li>
66        <li>XPCOM encuentra y procesa el <i>manifiesto del compon
>ente</i> (ve {{ Anch("Manifiestos de Componentes") }} abajo). 
67        </li>
68        <li>Si hay nuevos componentes, XPCOM los registra:
69          <ol>
70            <li>XPCOM llama el arranque del autoregistro.
71            </li>
72            <li>XPCOM registra los nuevos componentes.
73            </li>
74            <li>XPCOM llama el fin del autoregistro.
75            </li>
76          </ol>
77        </li>
78        <li>Arranque completo de XPCOM: XPCOM notifica que ha ini
>ciado. 
79        </li>
80      </ol>
81      <p>
82        Los manifiestos de Componentes y bibliotecas de tipos son
> descritos en la siguiente sección, {{ Anch("Registro de Manifies 
>tos de XPCOM") }}. 
83      </p>
84    </div>
85    <h4 id="Registro_de_Manifiestos_de_XPCOM" name="Registro_de_M
>anifiestos_de_XPCOM"> 
86      Registro de Manifiestos de XPCOM
87    </h4>
88    <p>
89      XPCOM usa archivos especiales llamados manifiestos para cam
>biar y guardar información acerca de los componentes en el sistem 
>a local. Hay dos tipos de manifiestos que usa XPCOM para cambiar  
>componentes: 
90    </p>
91    <h5 id="Manifiestos_de_Componente" name="Manifiestos_de_Compo
>nente"> 
92      Manifiestos de Componente
93    </h5>
94    <p>
95      Cuando XPCOM inicia por primera vez, busca el <i>manifiesto
> de componentes</i> que es un archivo que lista todos los compone 
>ntes registrados y guarda detalles de lo que exactamente puede ha 
>cer cada componente. XPCOM usa el manifiesto de componentes para  
>determinar que componentes han sido sobreescritos. Empezando en M 
>ozilla 1.2, este archivo es llamado <code>compreg.dat</code> y ex 
>iste en el directorio <i>components</i>, pero hay esfuerzos por m 
>overlo fuera de esta ubicación a una ubicación menos centrada en  
>la aplicación y más centrada en el usuario. Cualquier aplicación  
>bassada en Gecko puede escoger ponerlo en otro lado. XPCOM lee es 
>te archivo dentro de una base de datos en memoria. 
96    </p>
97    <div class="side-note">
98      <p>
99        {{ Block-title("Manifiestos de Componentes") }}
100      </p>
101      <p>
102        El manifiesto de componente es una correlación de archivo
>s a componentes y de componentes a clases. Especifica la siguient 
>e información: 
103      </p>
104      <ul>
105        <li>Ubicación en disco de los componentes registrados con
> el tamaño de archivo 
106        </li>
107        <li>ID de Clase relacionado a la Ubicación.
108        </li>
109        <li>Contract ID relacionado al ID de Clase.
110        </li>
111      </ul>
112      <p>
113        El manifiesto del componente relaciona archivos de compon
>entes a identificadores únicos para las implementaciones específi 
>cas (IDs de Clase), que en su momento son relacionados a identifi 
>cadores de componente más generales (contract IDs). 
114      </p>
115    </div>
116    <h5 id="Manifiestos_de_Bibliotecas_de_Tipos" name="Manifiesto
>s_de_Bibliotecas_de_Tipos"> 
117      Manifiestos de Bibliotecas de Tipos
118    </h5>
119    <p>
120      Otro archivo importante que lee XPCOM es el <i>manifiesto d
>e bibliotecas de tipos</i>. Este archivo tambien se localiza en e 
>l directorio <i>components</i> y se llama <code>xpti.dat</code>.  
>Incluye la ubicación y direcciones de búsqueda de todas las bibli 
>otecas de tipos en el sistema. este archivo también lista todas l 
>as interfaces conocidas y enlaces a los archivos de bibliotecas d 
>e tipos que definen estas estructuras de interfaces. Estos archiv 
>os de bibliotecas de tipos son el core para que XPCOM pueda ser s 
>cript y de la arquitectura de componentes binarios de XPCOM. 
121    </p>
122    <div class="side-note">
123      <p>
124        {{ Block-title("Manifiestos de Bibliotecas de Tipos") }} 
>Los manifiestos de bibliotecas de tipos contienen la siguiente in 
>formación: 
125      </p>
126      <ul>
127        <li>ubicación de todos los archivos de bibliotecas de tip
>os 
128        </li>
129        <li>correlación de todas las interfaces conocidas y bibli
>otecas de tipos donde están definidas estas estructuras. 
130        </li>
131      </ul>
132    </div>
133    <p>
134      Using the data in these two manifests, XPCOM knows exactly 
>which component libraries have been installed and what implementa 
>tions go with which interfaces. Additionally, it relates the comp 
>onents to the type libraries in which the binary representations  
>of the interfaces they support are defined. 
135    </p>
136    <p>
137      The next section describes how to hook into the XPCOM start
>up and registration process and make the data about your componen 
>t available in these manifests, so that your component will be fo 
>und and registered at startup. 
138    </p>
139    <h4 id="M.C3.A9todos_de_Registro_en_XPCOM" name="M.C3.A9todos
>_de_Registro_en_XPCOM"> 
140      Métodos de Registro en XPCOM
141    </h4>
142    <div class="side-note">
143      <p>
144        {{ Block-title("What Is XPCOM Registration?") }}
145      </p>
146      <p>
147        In a nutshell, registration is the process that makes XPC
>OM aware of your component(s). As this section and the next descr 
>ibe, you can register your component explicitly during installati 
>on, or with the <code>regxpcom</code> program, or you can use the 
> autoregistration methods in the Service Manager to find and regi 
>ster components in a specified components directory: 
148      </p>
149      <ul>
150        <li>XPInstall APIs
151        </li>
152        <li>
153          <code>regxpcom</code> command-line tool
154        </li>
155        <li>
156          <code>nsIComponentRegistrar</code> APIs from Service Ma
>nager 
157        </li>
158      </ul>
159      <p>
160        The registration process is fairly involved. This section
> introduces it in terms of XPCOM initialization, and the next cha 
>pter describes what you have to do in your component code to regi 
>ster your component with XPCOM. 
161      </p>
162    </div>
163    <p>
164      Once the manifest files are read in, XPCOM checks to see if
> there are any components that need to be registered. There are t 
>wo supported ways to go about registering your XPCOM component. T 
>he first is to use <i>XPInstall</i>, which is an installation tec 
>hnology that may or may not come with a Gecko application and pro 
>vides interfaces for registering your component during installati 
>on. Another, more explicit way to register your component is to r 
>un the application <code>regxpcom</code>, which is built as part  
>of Mozilla and is also available in the Gecko SDK. <code>regxpcom 
></code> registers your component in the default component registr 
>y. 
165    </p>
166    <p>
167      A Gecko embedding application may also provide its own way 
>of registering XPCOM components using the interface that is in fa 
>ct used by both XPInstall and <code>regxpcom</code>, <code>nsICom 
>ponentRegistrar</code>. An application, for example, could provid 
>e a "registration-less" component directory whose components are  
>automatically registered at startup and unregistered at shutdown. 
> Component discovery does not currently happen automatically in n 
>on-debug builds of Gecko, however. 
168    </p>
169    <p>
170      When the registration process begins, XPCOM broadcasts to a
>ll registered observers a notification that says XPCOM has begun  
>the registration of new components. After all components are regi 
>stered, another notification is fired saying that XPCOM is done w 
>ith the registration step. The <code>nsIObserver</code> interface 
> that handles this notification is discussed in <a href="es/Creat 
>ing_XPCOM_Components/Starting_WebLock">Starting WebLock</a>. 
171    </p>
172    <p>
173      Once registration is complete and the notifications have fi
>red, XPCOM is ready to be used by the application. If XPCOM regis 
>tered your component, then it will be available to other parts of 
> the XPCOM system. The {{ Anch("XPCOM Initialization") }} section 
> in this chapter describes registration in more detail. 
174    </p>
175    <h4 id="Autoregistro" name="Autoregistro">
176      Autoregistro
177    </h4>
178    <p>
179      The term <i>autoregistration</i> is sometimes used synonymo
>usly with registration in XPCOM. In the {{ Anch("What Is XPCOM Re 
>gistration?") }} note, we describe the three ways you can registe 
>r components with XPCOM. Sometimes, applications use the <code>ns 
>IComponentRegistrar</code> interface and create their own code fo 
>r watching a particular directory and registering new components  
>that are added there, which is what's often referred to as <i>aut 
>oregistration</i>. You should always know what the installation a 
>nd registration requirements are for the applications that will b 
>e using your component. 
180    </p>
181    <h4 id="El_Proceso_de_Paro" name="El_Proceso_de_Paro">
182      El Proceso de Paro
183    </h4>
184    <p>
185      When the application is ready to shutdown XPCOM, it calls <
>code>NS_ShutdownXPCOM</code>. When that method is called, the fol 
>lowing sequence of events occurs: 
186    </p>
187    <ol>
188      <li>XPCOM fires a shutdown notification to all registered o
>bservers. 
189      </li>
190      <li>XPCOM closes down the Component Manager, the Service Ma
>nager and associated services. 
191      </li>
192      <li>XPCOM frees all global services.
193      </li>
194      <li>NS_ShutdownXPCOM returns and the application may exit n
>ormally. 
195      </li>
196    </ol>
197    <div class="side-note">
198      <p>
199        {{ Block-title("The Unstoppable Shutdown") }}
200      </p>
201      <p>
202        Note that shutdown observation is unstoppable. In other w
>ords, the event you observe cannot be used to implement something 
> like a "Are you sure you want to Quit?" dialog. Rather, the shut 
>down event gives the component or embedding application a last ch 
>ance to clean up any leftovers before they are released. In order 
> to support something like an "Are you sure you want to quit" dia 
>log, the application needs to provide a higher-level event (e.g., 
> <code>startShutdown()</code>) which allows for cancellation. 
203      </p>
204      <p>
205        Note also that XPCOM services may deny you access once yo
>u have received the shutdown notification. It is possible that XP 
>COM will return an error if you access the <code>nsIServiceManage 
>r</code> at that point, for example, so you may have to keep a re 
>ference-counted pointer to the service you are interested in usin 
>g during this notification. 
206      </p>
207    </div>
208    <h4 id="Component_Loaders" name="Component_Loaders">
209      Component Loaders
210    </h4>
211    <p>
212      Components can be written in many languages. So far this bo
>ok has been focusing on "native components," shared libraries exp 
>orting a <code>NSGetModule</code> symbol. But if there is a <i>co 
>mponent loader</i> for Javascript installed, then you can also wr 
>ite a JavaScript component. 
213    </p>
214    <p>
215      To register, unregister, load and manage various component 
>types, XPCOM abstracts the interface between the XPCOM component  
>and XPCOM with the Component Loader. This loader is responsible f 
>or initialization, loading, unloading, and supporting the <code>n 
>sIModule</code> interface on behalf of each component. It is the  
>Component Loader's responsibility to provide scriptable component 
> support. 
216    </p>
217    <p>
218      When building a "native" component, the component loader lo
>oks for an exported symbol from the components shared library. "N 
>ative" here includes any language that can generate a platform na 
>tive dynamically loaded library. Scripting languages and other "n 
>on-native" languages usually have no way to build native librarie 
>s. In order to have "non-native" XPCOM components work, XPCOM mus 
>t have a special component loader which knows how to deal with th 
>ese type of components. 
219    </p>
220    <p>
221      XPConnect, for example, provides a component loader that ma
>kes the various types, including the interfaces and their paramet 
>ers, available to JavaScript. Each language supported by XPCOM mu 
>st have a component loader. 
222    </p>
223    <h4 id="Tres_Partes_de_una_Biblioteca_de_Componentes_XPCOM" n
>ame="Tres_Partes_de_una_Biblioteca_de_Componentes_XPCOM"> 
224      Tres Partes de una Biblioteca de Componentes XPCOM
225    </h4>
226    <p>
227      XPCOM is like an onion<span class="comment">or a parfait! E
>verybody likes parfaits</span>. XPCOM components have at least th 
>ree layers. From the innermost and moving outward these layers in 
>clude: 
228    </p>
229    <ul>
230      <li>The core XPCOM object
231      </li>
232      <li>The factory code
233      </li>
234      <li>The module code
235      </li>
236    </ul>
237    <p>
238      The core XPCOM object is the object that will implement the
> functionality you need. For example, this is the object that may 
> start a network download and implement interfaces that will list 
>en to the progress. Or the object may provide a new content type  
>handler. Whatever it does, this object is at the core of the XPCO 
>M component, and the other layers are supporting it, plugging it  
>into the XPCOM system. A single library may have many of these co 
>re objects. 
239    </p>
240    <p>
241      One layer above the core object is the factory code. The fa
>ctory object provides a basic abstraction of the core XPCOM objec 
>t. <a href="es/Creating_XPCOM_Components/An_Overview_of_XPCOM">An 
> Overview of XPCOM</a> discussed the factory design pattern that' 
>s used in a factory object. At this layer of the XPCOM Component  
>Library, the factory objects are factories for the core XPCOM obj 
>ects of the layer below. 
242    </p>
243    <p>
244      One more layer outward is the module code. The module inter
>face provides yet another abstraction - this time of the factorie 
>s - and allows for multiple factory objects. From the outside of  
>the component library, there is only the single entry point, <cod 
>e>NSGetModule()</code>. This point of entry may fan out to any nu 
>mber of factories, and from there, to any number of XPCOM objects 
>. 
245    </p>
246    <p>
247      The following chapter details these layers in terms of the 
>XPCOM interfaces that represent them. Here we will just introduce 
> them. The factory design pattern in XPCOM is represented by the  
><code>nsIFactory</code> interface. The module layer is represente 
>d by the <code>nsIModule</code> interface. Most component librari 
>es only need these two interfaces, along with the <code>nsISuppor 
>ts</code> interface, to have XPCOM load, recognize, and use their 
> core object code. 
248    </p>
249    <p>
250      In the next section, we'll be writing the code that actuall
>y compiles into a component library, and you will see how each la 
>yer is implemented and how each interface is used. Following this 
> initial, verbose demonstration of the APIs, we will introduce a  
>faster more generic way of implementing the module and factory co 
>de using macros, which can make components much easier to create. 
251    </p>
252    <h3 id="XPCOM_Glue" name="XPCOM_Glue">
253      XPCOM Glue
254    </h3>
255    <p>
256      XPCOM contains a lot of stuff. Most of the XPCOM interfaces
> are not frozen and are meant to be used only by the Gecko intern 
>als, not by clients. XPCOM provides many data structures from lin 
>ked lists to <a class="external" href="http://en.wikipedia.org/wi 
>ki/AVL_tree">AVL trees</a>. Instead of writing your own linked li 
>st, it's tempting to reuse <code>nsVoidArray</code> or another pu 
>blicly available class, but this might be a fatal mistake. At any 
> time the class can change and give you unexpected behavior. 
257    </p>
258    <p>
259      XPCOM makes for a very open environment. At runtime you can
> acquire any service or component merely by knowing a CID, or Con 
>tract ID, and an IID. At last count there were over 1300 interfac 
>es defined in XPIDL. Of those 1300 interfaces, less than 100 were 
> frozen, which means that a developer has a good chance of stumbl 
>ing upon useful interfaces that aren't frozen. If an interface is 
>n't explicitly marked "FROZEN" in the IDL comments, however - and 
> most of them aren't - it will cause your component to possibly b 
>reak or crash when the version changes. 
260    </p>
261    <h4 id="La_Biblioteca_Glue" name="La_Biblioteca_Glue">
262      La Biblioteca Glue
263    </h4>
264    <p>
265      In general you should avoid any unfrozen interfaces, any sy
>mbols in XPCOM, or any other part of Gecko libraries that aren't  
>frozen. However, there are some unfrozen tools in XPCOM that are  
>used so often they are practically required parts of component pr 
>ogramming. 
266    </p>
267    <p>
268      The smart pointer class, <code>nsCOMPtr</code>, for example
>, which can make reference counting a lot less tedious and error- 
>prone, is not actually frozen, and neither are <code>nsDebug</cod 
>e>, a class for aiding in tracking down bugs, or <code>nsMemory</ 
>code>, a class to ensure that everyone uses the same heap, generi 
>c factory, and module. Instead of asking every developer to find  
>and copy these various files into their own application, XPCOM pr 
>ovides a single library of "not-ready-to-freeze-but-really-helpfu 
>l" classes that you can link into your application, as the follow 
>ing figure demonstrates. 
269    </p>
270    <p>
271      {{ Block-title("XPCOM Glue and Tools") }}
272    </p>
273    <p>
274      <img alt="Image:xpcom-glue-tools.png" fileid="0" src="File:
>es/Media_Gallery/Xpcom-glue-tools.png"> 
275    </p>
276    <p>
277      This is the glue library. It provides a bridge, or "glue" l
>ayer, between your component and XPCOM. 
278    </p>
279    <p>
280      A version of the glue library is built into XPCOM, and when
> your component uses it, it links a snapshot of this library: it  
>includes a copy of these unfrozen classes directly, which allows  
>the XPCOM library version to change without affecting the softwar 
>e. There is a slight footprint penalty to linking directly, but t 
>his gives your component freedom to work in any recent environmen 
>t. If footprint is a big issue in your component or application,  
>you can trim out the pieces you don't need. 
281    </p>
282    <h4 id="Clases_de_Cadenas_de_XPCOM" name="Clases_de_Cadenas_d
>e_XPCOM"> 
283      Clases de Cadenas de XPCOM
284    </h4>
285    <p>
286      The base string types that XPCOM uses are <code>nsAString</
>code> and <code>nsACString</code>. These classes are described in 
> the Mozilla String Guide (see <a href="es/Creating_XPCOM_Compone 
>nts/Resources#Gecko_Resources">Gecko Resources</a>). 
287    </p>
288    <p>
289      The string classes that implement these abstract classes ar
>e another set of helpful, unfrozen classes in XPCOM. Most compone 
>nts and embedding applications need to link to some kind of strin 
>g classes in order to utilize certain Gecko APIs, but the string  
>code that Mozilla uses is highly complex and even more expensive  
>than the glue code in terms of footprint (~100k). <code>nsEmbedSt 
>ring</code> and <code>nsEmbedCString</code> are available as very 
> light string class implementations for component development, es 
>pecially in small embedded applications. This string implementati 
>on does the bare minimum to support <code>nsAString</code>/<code> 
>nsACString</code> string classes. 
290    </p>
291    <p>
292      In your own component, you can go "slim" and restrict yours
>elf to the <code>nsEmbedString</code> or go "hog wild" and use al 
>l of the functionality of the other strings. WebLock restricts it 
>self to using the simple <code>nsEmbedString</code> family of cla 
>sses. 
293    </p>
294    <p>
295      {{ Block-title("String Classes and XPCOM") }}
296    </p>
297    <p>
298      <img alt="Image:strings-in-xpcom.png" fileid="0" src="File:
>es/Media_Gallery/Strings-in-xpcom.png"> 
299    </p>
300    <p>
301      The glue library provides stub functions for the public fun
>ctions that XPCOM provides (see {{ Source("xpcom/build/nsXPCOM.h" 
>) }}). When the glue library is initialized, it dynamically loads 
> these symbols from the XPCOM library, which allows the component 
> to avoid linking directly with the XPCOM library. You shouldn't  
>have to link to the XPCOM library to create a XPCOM component - i 
>n fact, if your component has to, then something is wrong. {{ Pre 
>viousNext("Creating XPCOM Components:Using XPCOM Components", "Cr 
>eating XPCOM Components:Creating the Component Code") }} {{ CXCLi 
>censeBlock() }} 
302    </p>

Volver al historial