667
edits
Changes
m
→Using nsICookieManger from JavaScript
As you would expect from our XPCOM lab, [https://developer.mozilla.org/En/NsICookieManager nsICookieManager] is really two parts:
* a public interface in the form of an IDL file, [http://hg.mozilla.org/mozilla-central/file/0cd41f599080/netwerk/cookie/public/nsICookiensICookieManager.idl nsICookieManager.idl], which lives in [http://hg.mozilla.org/mozilla-central/file/0cd41f599080/netwerk/cookie/public netwerk/cookie/public]
* C++ code that implements this interface, in the form of [http://hg.mozilla.org/mozilla-central/file/0cd41f599080/netwerk/cookie/src/nsCookieService.cpp nsCookieService.cpp] and [http://hg.mozilla.org/mozilla-central/file/0cd41f599080/netwerk/cookie/src/nsCookieService.h nsCookieService.h], located in [http://hg.mozilla.org/mozilla-central/file/0cd41f599080/netwerk/cookie/src netwerk/cookie/src].
Notice that the C++ code is not named the same as the IDL. In fact, nsCookieService.cpp/h defines a single class that implements all of '''nsICookieService''' and '''nsICookieManager2''', which includes '''nsICookieManger''' through inheritance.
Why have '''nsICookieManger2'''? Why not simply add more to '''nsICookieManager'''? The nsICookieManager interface is a '''[https://developer.mozilla.org/En/Interfaces/About_Frozen_Interfaces Frozen Interface'''], which means that it is guaranteed not to change in the future, and developers can use it knowing that nothing will happen to it down the road. Any component that implements this interface must also guarantee that the method and attributes don't change their signature.
What if you need to add something? It will happen eventually. The typical answer is to add a new interface that inherits from the old one, bumping a version number by one. This explains the existence of '''nsICookieManager2''', and is a common design pattern in Mozilla.
nsCOMPtr is designed to help developers not leak memory, and to make it easy to work with interfaces. It is a so-called smart pointer: a template class that acts just like a regular pointer, but which adds AddRef, Release, and QueryInterface.
An XPCOM object is accessed via a pointer to an abstract base class (the interface type). Each interface pointer keeps track of how many references to it are being held. As new variables are created and clients get new references, AddRef is called, and the number goes up. When interface pointers go out of scope, the nsCOMPtr decreases the reference count, and when that goes to 0, deletes the object automatically. The [https://developer.mozilla.org/En/NsISupports/QueryInterface QueryInterface] method of nsCOMPtr is used to do runtime type discovery, allowing us to see if a type implements an interface, and if it does, obtain a pointer to that interface. For example, we know that nsICookieManager2 inherits from nsICookieManager, so given an nsICookieManager we might wish to obtain a pointer to an nsICookieManager2 in order to get extra functionality: nsCOMPtr<nsICookieManager> cookieManager = do_GetService(NS_COOKIEMANAGER_CONTRACTID); if (cookieManager) { nsCOMPtr<nsICookieManager2> cookieManager2 = do_QueryInterface(cookieManager); if (cookieManager2) { ... } } NOTE: it is more common (and advisable) to call the helper do_QueryInterface instead of using QueryInterface directly. See the [https://developer.mozilla.org/En/Using_nsCOMPtr/Reference_Manual nsCOMPtr Reference Manual].
=== Services ===
}
== Using nsICookieManger from in JavaScript ==
Doing the same thing from JavaScript is even easier, but requires some different steps and sytax:
