mozilla

Compare Revisions

User:Sdtiner

Change Revisions

Revision 204000:

Revision 204000 by Sdtiner on

Revision 204001:

Revision 204001 by Sdtiner on

Title:
User:Sdtiner
User:Sdtiner
Slug:
User:Sdtiner
User:Sdtiner
Content:

Revision 204000
Revision 204001
t7    <div>t
8      <p>
9        <b><font style="font-size:160%">Bird's Eye View of the Mo
>zilla Framework</font></b> 
10      </p>
11      <ul>
12        <li>Author: Susan D. Tiner
13        </li>
14        <li>Last Updated Date: 11/23/05
15        </li>
16      </ul>
17    </div>
18    <h2 name="Statement_of_Purpose">
19      Statement of Purpose
20    </h2>
21    <p>
22      The purpose of this article is to provide a high-level tech
>nical overview of the architecture of the extensible, object-base 
>d Mozilla application framework by examining what happens when th 
>e user performs a simple user interface (UI) action such as click 
>ing a link in the <i>Contents Panel</i> of the <i>Help Viewer</i> 
> window shown below. The article focuses on the architecture of t 
>he overall framework supporting the Mozilla application suite, no 
>t the architecture of the individual applications themselves. 
23    </p>
24    <p>
25      <img alt="Image:Help.PNG" src="File:en/Media_Gallery/Help.P
>NG"> 
26    </p>
27    <h2 name="Prerequisites">
28      Prerequisites
29    </h2>
30    <p>
31      This article assumes you have access to Mozilla sources and
> are familiar with the directory structure of the source tree. Th 
>e code samples in the article are based on Mozilla/5.0 (Windows;  
>U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051104 SeaMonkey/1.1a 
> from a new source tree checked out 11/04/05. The build ID is 200 
>5110409. The <i>Help Viewer</i> files referenced in the article a 
>re located in 
32    </p>
33    <p>
34      /seamonkey/extensions/help/
35    </p>
36    <p>
37      This article also assumes you are familiar with the JavaScr
>ipt and C++ programming languages, object-oriented programming (O 
>OP) terminology and design concepts, the Microsoft® Component Obj 
>ect Model <a class="external" href="http://www.microsoft.com/com/ 
>default.mspx">COM</a>), and the CORBA OMG Interface Definition La 
>nguage (<a class="external" href="http://www.omg.org/gettingstart 
>ed/omg_idl.htm">(IDL)</a>. 
38    </p>
39    <h2 name="Organization">
40      Organization
41    </h2>
42    <p>
43      This article first covers some conceptual groundwork, then 
>walks through a user scenario to illustrate how key Mozilla archi 
>tectural components work together to support a simple <i>Help Vie 
>wer</i> UI action. 
44    </p>
45    <h2 name="Framework_Layers">
46      Framework Layers
47    </h2>
48    <p>
49      At a high level, you can think of the Mozilla framework as 
>consisting of a suite of applications, each of which is organized 
> into three basic layers depicted in Figure 1. 
50    </p>
51    <p>
52      <br>
53      <i><b>Figure 1.</b></i>
54    </p>
55    <p>
56      <img alt="Image:Aol.png" src="File:en/Media_Gallery/Aol.png
>"> 
57    </p>
58    <h3 name="User_Interface_.28UI.29_Widgets_and_Services">
59      User Interface (UI) Widgets and Services
60    </h3>
61    <p>
62      The <a class="external" href="http://www.xfree86.org/curren
>t/X.7.html">X Window System</a> Toolkit defines the term <i>widge 
>t</i> as a pre-defined object that encapsulates both the command  
>actions and data associated with a graphical user interface (GUI) 
> control. The various X Toolkit implementations provide a set of  
>widgets for UI controls such as menus, command buttons, dialog bo 
>xes and scroll bars. The Mozilla <a class="external" href="http:/ 
>/www.mozilla.org/xpfe/">XPToolkit</a> module provides a similar s 
>et of facilities for building cross-platform UI controls implemen 
>ted as <a class="external" href="http://developer.mozilla.org/en/ 
>docs/XUL_Tutorial">XML User Interface Language (XUL)</a> packages 
>. A <a class="external" href="http://www.mozilla.org/xpfe/xptoolk 
>it/overview.html">XUL package</a> consists of 
63    </p>
64    <ul>
65      <li>a XUL description of the UI widget
66      </li>
67      <li>
68        <a class="external" href="http://www.w3.org/Style/CSS/">C
>ascading Style Sheets</a> customizing appearance 
69      </li>
70      <li>JavaScript services implementing the UI behavior
71      </li>
72    </ul>
73    <p>
74      A package (also known as <a class="external" href="http://w
>ww.mozilla.org/docs/xul/xulnotes/xulnote_beasts.html"><i>chrome</ 
>i></a>) is really just a bundling of a set of UI widgets and asso 
>ciated services implementing a particular application feature. Ch 
>rome and <a class="external" href="http://developer.mozilla.org/e 
>n/docs/Extensions">Extensions</a> are examples of packages. 
75    </p>
76    <h3 name="Content_.28DOM.29">
77      Content (DOM)
78    </h3>
79    <p>
80      The Mozilla <a class="external" href="http://developer.mozi
>lla.org/en/docs/DOM">Document Object Model (DOM)</a> specifies a  
>logical tree structure for storing UI and document content, and p 
>rovides an API (Application Programming Interface) for accessing  
>and manipulating the content. An application such as the browser  
>may have one or more open documents accessible via DOM APIs. When 
> an HTML, XML, SVG or other type of document is loaded, the <a cl 
>ass="external" href="http://www.mozilla.org/newlayout/">NGLayout< 
>/a> engine (also known as Gecko) parses the contents into a DOM t 
>ree, and handles the layout and rendering of the document pages.  
>The NGLayout engine also parses XUL UI controls into a DOM tree a 
>nd handles rendering of the UI. 
81    </p>
82    <h3 name="Core_Services">
83      Core Services
84    </h3>
85    <p>
86      Modules such as the NGLayout engine comprise the core appli
>cation services available to 
87    </p>
88    <ul>
89      <li>other core modules, and
90      </li>
91      <li>XUL packages
92      </li>
93    </ul>
94    <p>
95      Core application modules are implemented as a set of one or
> more <a class="external" href="http://developer.mozilla.org/en/d 
>ocs/Creating_XPCOM_Components">XPCOM</a> (Cross-Platform COM) obj 
>ects. 
96    </p>
97    <h2 name="XPCOM_Object_Model">
98      XPCOM Object Model
99    </h2>
100    <p>
101      Before getting into the details of the UI example, it's hel
>pful to have a basic understanding of the XPCOM object model. Moz 
>illa architectural modules are comprised of groups of related XPC 
>OM objects that provide services to and access services from each 
> other through dynamically queryable interfaces. 
102    </p>
103    <h3 name="Object_Model_At_a_Glance">
104      Object Model At a Glance
105    </h3>
106    <p>
107      Mozilla dynamically loads and integrates core modules and X
>UL packages into the runtime environment on startup. Once loaded, 
> a module or package has full access to the XPCOM objects of all  
>the other modules in the runtime environment. The ability to dyna 
>mically integrate modules and packages at startup is a powerful b 
>enefit of the object model, which defines a module as a set of on 
>e or more XPCOM objects called <i>components</i>. These objects p 
>rovide services to client packages and modules and access service 
>s provided by other modules through dynamically queryable interfa 
>ces. Figure 2 shows this structure. 
108    </p>
109    <p>
110      <br>
111      <i><b>Figure 2.</b></i>
112    </p>
113    <p>
114      <img alt="Image:Object.png" src="File:en/Media_Gallery/Obje
>ct.png"> 
115    </p>
116    <p>
117      In the diagram above, each horizontal line extending from a
>n object and terminated by an open circle indicates an interface  
>to the object. The client object does not need to know anything a 
>bout the internal structure or implementation of the provider obj 
>ect in order to take advantage of its services. The client simply 
> queries the provider for a particular service, and if available, 
> accesses that service through an interface defined in <a class=" 
>external" href="http://developer.mozilla.org/en/docs/XPIDL:Syntax 
>">XPIDL</a>(Cross-Platform IDL), derived from the CORBA IDL. The  
>XPIDL interface description is independent of the programming lan 
>guage used to implement the object itself. For example, a JavaScr 
>ipt object or C++ class could both implement the same XPIDL inter 
>face. 
118    </p>
119    <p>
120      Scripting languages such as JavaScript cannot directly acce
>ss XPCOM components, but access them indirectly using <a class="e 
>xternal" href="http://www.mozilla.org/scriptable/">XPConnect</a>. 
> XPConnect also provides a required layer for XPCOM components wr 
>itten in a scripting language. 
121    </p>
122    <p>
123      Let’s consider a <a class="external" href="http://www.xml.c
>om/pub/a/2001/01/24/rdf.html">Resource Description Framework (RDF 
>)</a> example, where RDF is a framework for describing and interc 
>hanging <i>metadata</i>, that is, information about information.  
>In this example, we’re interested in the RDF sub-graph underlying 
> the <i>Contents Panel</i> widget within the <i>Help Viewer</i> w 
>indow. Suppose the client already has an <code>nsIRDFDataSource</ 
>code> object representing a sub-graph of an RDF graph and calls < 
>code>nsIRDFDataSource.GetTarget(resource, NC_LINK, true)</code> t 
>o obtain an <code>nsIRDFNode</code> representing a specific node  
>in the graph, in this case a link to a <i>Help Viewer</i> documen 
>t page. The client is completely unaware of which C++ class (or o 
>ther language) actually implements <code>nsIRDFNode</code>; it on 
>ly interacts with the IDL interface. 
124    </p>
125    <p>
126      The client would like to ask the <code>nsIRDFNode</code> wh
>ether its supports <code>nsIRDFLiteral</code>. An <code>nsIRDFNod 
>e</code> must be an <code>nsIRDFLiteral</code> or an <code>nsIRDF 
>Resource</code>. The link is a literal, so the client wants <code 
>>nsIRDFLiteral</code>. Since all XPCOM interfaces inherit the bas 
>e interface <code>nsISupports</code>, the client can ask whether  
><code>nsIRDFNode</code> supports <code>nsIRDFLiteral</code> by ca 
>lling <code>nsIRDFNode.QueryInterface()</code>, a method in the < 
>code>nsISupports</code> interface. 
127    </p>
128    <pre>
129[scriptable, uuid(00000000-0000-0000-c000-000000000046)]
130  interface nsISupports {
131  void QueryInterface(in nsIIDRef uuid, 
132            iid_is(uuid),retval] out nsQIResult result);
133  [noscript, notxpcom] nsrefcnt AddRef();
134  [noscript, notxpcom] nsrefcnt Release();
135};
136</pre>
137    <p>
138      The <code>uuid</code> parameter to <code>QueryInterfdace()<
>/code> is the IID uniqely identifying the interface. 
139    </p>
140    <p>
141      If <code>nsIRDFNode</code> doesn't support <code>nsIRDFLite
>ral</code>, it returns <code>null</code> and it's up to the clien 
>t to choose an alternate course of action. 
142    </p>
143    <p>
144      The XPCOM component keeps track of all interface pointers c
>urrently held by its clients using an internal reference count it 
> increments via client calls to <code>AddRef()</code>. It is up t 
>o the client to call <code>Release()</code> when it no longer nee 
>ds the interface. <code>Release()</code> decrements the reference 
> count and then the object becomes a candidate for destruction. 
145    </p>
146    <p>
147      JavaScript handles its own garbage collection, so it doesn’
>t need to call <code>AddRef()</code> and <code>Release()</code>. 
148    </p>
149    <h3 name="Inside_an_XPCOM_Component">
150      Inside an XPCOM Component
151    </h3>
152    <p>
153      Figure 3 shows a more detailed view of an XPCOM component.
154    </p>
155    <p>
156      <br>
157      <i><b>Figure 3.</b></i>
158    </p>
159    <p>
160      <img alt="Image:Xpcom.png" src="File:en/Media_Gallery/Xpcom
>.png"> 
161    </p>
162    <p>
163      As noted earlier, the component-specific interfaces of an X
>PCOM component all inherit from <code>nsISupports</code>. Likewis 
>e, an XPCOM component must implement 
164    </p>
165    <ul>
166      <li>
167        <code>nsIFactory</code>, which provides a mechanism for c
>reating an object without having access to the class declaration  
>for that object, 
168      </li>
169      <li>
170        <code>nsIModule</code>, which provides a mechanism for re
>gistering and unregistering the XPCOM component, as well as for a 
>ccessing the underlying class objects implementing the IDL interf 
>aces, and 
171      </li>
172      <li>
173        <code>NSGetModule()</code>, the entry point used to load 
>the XPCOM component. 
174      </li>
175    </ul>
176    <p>
177      XPCOM components also link with a set of XPCOM utilities, s
>uch as strings, smart pointers, basic assertion and condition che 
>cking. These utilities are referred to as XPCOM <a class="externa 
>l" href="http://developer.mozilla.org/en/docs/XPCOM_Glue"><i>glue 
></i></a>. 
178    </p>
179    <p>
180      At startup, the core application component identifies and l
>oads all of the different XPCOM components comprising the core ap 
>plication services and builds a central registry it uses to gener 
>ate instances of XPCOM components and instances of interface impl 
>ementation classes on demand. 
181    </p>
182    <h3 name="XPCOM_in_Summary">
183      XPCOM in Summary
184    </h3>
185    <p>
186      To summarize, the XPCOM object model
187    </p>
188    <ul>
189      <li>specifies the structure of XPCOM components,
190      </li>
191      <li>builds a central registry based on the XPCOM components
> loaded at startup, 
192      </li>
193      <li>generates XPCOM component instances on demand using the
> registry, which specifies the supported interfaces, their corres 
>ponding implementation objects, and the <code>nsIFactory</code> i 
>nterface, 
194      </li>
195      <li>provides API facilities clients can use to dynamically 
>create XPCOM components, and 
196      </li>
197      <li>specifies the mechanism clients use to query an XPCOM c
>omponent for one of its interfaces, and to release the interface  
>when it’s no longer needed. 
198      </li>
199    </ul>
200    <h2 name="JavaScript_Client_Example">
201      JavaScript Client Example
202    </h2>
203    <p>
204      Suppose the JavaScript service in Figure 2 is <code>getLink
>()</code> in Help.js, which responds to the user clicking on a li 
>nk in the <i>Contents Panel</i> within the <i>Help Viewer</i> win 
>dow by obtaining the link from the <i>Contents Panel</i> elements 
> stored in a DOM tree. As a client, <code>getLink()</code> begins 
> by obtaining the <code>XULElement</code> in the DOM tree represe 
>nting the <i>Contents Panel</i>. 
205    </p>
206    <pre>
207var tocTree = document.getElementById("help-toc-panel");
208</pre>
209    <p>
210      The document object is a <a class="external" href="http://w
>ww.mozilla.org/xpfe/xptoolkit/xulintro.html"><code>XULDocument</c 
>ode></a>, and tocTree is the <i>Contents Panel</i> <code>XULEleme 
>nt</code>. Using the <code>database</code> attribute of the <code 
>>XULElement</code>, <code>getLink()</code> obtains an <code>nsIRD 
>FCompositeDataSource</code>, which presents the individual <code> 
>datasources</code> of the <code>XULElement</code> as a single RDF 
> graph. 
211    </p>
212    <pre>
213 
214var tocDS = tocTree.database;
215</pre>
216    <p>
217      <code>NsIRDFCompositeDataSource</code> inherits from <code>
>nsIRDFDataSource</code>. 
218    </p>
219    <p>
220      Help.js declares an <code>nsIRDFService</code> as a compile
> time constant at the beginning of the file. 
221    </p>
222    <pre>
223  
224const RDF = Components.classes["@mozilla.org/rdf/rdf-service;1"].
>getService(Components.interfaces.nsIRDFService); 
225</pre>
226    <p>
227      The <a class="external" href="http://www.mozilla.org/script
>able/components_object.html"><code>Components</code></a> object i 
>s made available to JavaScript via XPConnect; it serves as a brid 
>ge connecting JavaScript and XPCOM. 
228    </p>
229    <p>
230      <code>getLink()</code> uses the <code>nsIRDFService</code> 
>to obtain an <code>nsIRDFResource</code> for the requested link. 
231    </p>
232    <pre>
233 
234var resource = RDF.GetResource(rdfID);
235</pre>
236    <p>
237      <code>nsIRDFCompositeDataSource</code> inherits from <code>
>nsIRDFDataSource</code>, which supports a <code>GetTarget()</code 
>> method for obtaining the <code>nsIRDFNode</code> for a given re 
>source and property. 
238    </p>
239    <pre>
240 
241var link = tocDS.GetTarget(resource, NC_LINK, true);
242</pre>
243    <p>
244      Now that <code>getLink()</code> has the <code>nsIRDFNode</c
>ode> for the link, it can call <code>QueryInterface()</code> to c 
>heck whether the <code>nsIRDFLiteral</code> is supported. 
245    </p>
246    <pre>
247 
248link = link.QueryInterface(Components.interfaces.nsIRDFLiteral);
249</pre>
250    <p>
251      If <code>nsIRDFLiteral</code> is supported, <code>getLink()
></code> uses it to return the value of the link. Otherwise it ret 
>urns <code>null</code>. 
252    </p>
253    <pre>
254if (link)
255  return link.Value;
256else
257  return null;
258</pre>
259    <p>
260      The document page for the link is displayed in the <i>Help 
>Viewer</i> window. 
261    </p>
262    <p>
263      <br>
264      <a href="en/Bird's_Eye_View_of_the_Mozilla_Framework">Bird'
>s Eye View of the Mozilla Framework</a> 
265    </p>

Back to History