Difference between revisions of "Components and Interfaces"
(→Resources) |
|||
(15 intermediate revisions by 2 users not shown) | |||
Line 18: | Line 18: | ||
In Mozilla, there are several technologies used that build the codebase. You will find some lower level programming languages such as C/C++ in the core, and may find some higher level programming languages such as Javascript in extensions, components, etc... | In Mozilla, there are several technologies used that build the codebase. You will find some lower level programming languages such as C/C++ in the core, and may find some higher level programming languages such as Javascript in extensions, components, etc... | ||
− | These technologies are connected using the XPCOM | + | These technologies are connected using the XPCOM, XPIDL, etc... With these frameworks, developers can break up software projects into components. |
=== Component === | === Component === | ||
+ | Using XPCOM supports the object oriented approach, allowing code to encapsulate and inherent functionality and characteristics. | ||
− | XPCOM allows developers to connect their code to the rest of the Mozilla codebase. It is a cross platform technology which allows the code to be | + | XPCOM allows developers to connect their code to the rest of the Mozilla codebase. It is a cross platform technology which allows the code to be: |
− | |||
− | |||
− | |||
+ | * reusable | ||
+ | * updateable | ||
+ | * modular | ||
''For example, the CookieManager Component can be called from Javascript code'' | ''For example, the CookieManager Component can be called from Javascript code'' | ||
Line 32: | Line 33: | ||
// xpconnect to cookiemanager | // xpconnect to cookiemanager | ||
// get the cookie manager component in JavaScript | // get the cookie manager component in JavaScript | ||
− | var cookiemanager = Components.classes["@mozilla.org/ | + | '''var cookiemanager = Components.classes["@mozilla.org/cookiemanager;1"].getService();''' |
− | + | '''cookiemanager = cookiemanager.QueryInterface(Components.interfaces.nsICookieManager);''' | |
− | cookiemanager = cookiemanager.QueryInterface | ||
− | |||
// called as part of a largerDeleteAllCookies() function | // called as part of a largerDeleteAllCookies() function | ||
function FinalizeCookieDeletions() { | function FinalizeCookieDeletions() { | ||
for (var c=0; c<deletedCookies.length; c++) { | for (var c=0; c<deletedCookies.length; c++) { | ||
− | cookiemanager.remove(deletedCookies[c].host, | + | '''cookiemanager.remove(deletedCookies[c].host, deletedCookies[c].name, deletedCookies[c].path);''' |
− | |||
− | |||
− | |||
} | } | ||
deletedCookies.length = 0; | deletedCookies.length = 0; | ||
− | } | + | } |
+ | These components can be grouped together to become a Module. A component or several components (aka Module) are delivered as binary library. In Windows, libraries are .dll files; whereas, Unix libraries are DSO. | ||
=== Interface === | === Interface === | ||
+ | There are two fundamental issues in component and interface-based programming: | ||
+ | * lifetime (aka object ownership) | ||
+ | * interface querying (identifing components at run-time). | ||
+ | |||
+ | These issues are addressed by the nsISupports interface that every XPCOM object should implement. | ||
+ | |||
+ | The nsISupports interface is similar to the Object and other run-time interfaces built into Java and .NET. | ||
+ | |||
+ | The following is a simple example of an implemented nsISupports interface for the class Sample. | ||
+ | |||
+ | 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); | ||
+ | |||
+ | }; | ||
+ | |||
+ | nsISupports interface is explained well [http://www.mozilla.org/projects/xpcom/book/cxc/html/quicktour2.html#1003494 here]. | ||
== Related Links == | == Related Links == | ||
Line 58: | Line 79: | ||
*https://addons.mozilla.org/firefox/2230/ | *https://addons.mozilla.org/firefox/2230/ | ||
− | == | + | == Resources == |
+ | |||
+ | Links to Newsgroup: | ||
+ | * [news://news.mozilla.org/netscape.public.mozilla.xpcom mozilla.xpcom newsgroup] | ||
+ | |||
+ | Links to IRC Channels: | ||
+ | * [irc://irc.mozilla.org/developers #Developers] |
Latest revision as of 22:54, 4 October 2006
Contents
What are Components and Interfaces?
Components and Interfaces define and/or implement small pieces of modular code that can be reused in the codebase.
For example, Necko is the network library which is made up of several components such as HTTP, FTP, and other network protocol definitions and implementations.
Component
- A component is a small piece of reusable code.
- It is usually one of several in a module.
- A module is a binary library that groups components that provide some functionality.
Interface
- A interface defines the communication channels between components.
- These interfaces are reused to define unique components with the same characteristics and communication channels.
Components and Interfaces in Mozilla
In Mozilla, there are several technologies used that build the codebase. You will find some lower level programming languages such as C/C++ in the core, and may find some higher level programming languages such as Javascript in extensions, components, etc...
These technologies are connected using the XPCOM, XPIDL, etc... With these frameworks, developers can break up software projects into components.
Component
Using XPCOM supports the object oriented approach, allowing code to encapsulate and inherent functionality and characteristics.
XPCOM allows developers to connect their code to the rest of the Mozilla codebase. It is a cross platform technology which allows the code to be:
- reusable
- updateable
- modular
For example, the CookieManager Component can be called from Javascript code
// xpconnect to cookiemanager // get the cookie manager component in JavaScript var cookiemanager = Components.classes["@mozilla.org/cookiemanager;1"].getService(); cookiemanager = cookiemanager.QueryInterface(Components.interfaces.nsICookieManager); // called as part of a largerDeleteAllCookies() function function FinalizeCookieDeletions() { for (var c=0; c<deletedCookies.length; c++) { cookiemanager.remove(deletedCookies[c].host, deletedCookies[c].name, deletedCookies[c].path); } deletedCookies.length = 0; }
These components can be grouped together to become a Module. A component or several components (aka Module) are delivered as binary library. In Windows, libraries are .dll files; whereas, Unix libraries are DSO.
Interface
There are two fundamental issues in component and interface-based programming:
- lifetime (aka object ownership)
- interface querying (identifing components at run-time).
These issues are addressed by the nsISupports interface that every XPCOM object should implement.
The nsISupports interface is similar to the Object and other run-time interfaces built into Java and .NET.
The following is a simple example of an implemented nsISupports interface for the class Sample.
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); };
nsISupports interface is explained well here.
Related Links
- http://www.mozilla.org/projects/xpcom/book/cxc/html/index.html
- http://www.mozilla.org/projects/xpcom/book/cxc/html/quicktour2.html#1003424
- http://www.hacksrus.com/~ginda/cview/
- https://addons.mozilla.org/firefox/2230/
Resources
Links to Newsgroup:
Links to IRC Channels: