canmove, Confirmed users
2,056
edits
Site-Specific Preferences: Difference between revisions
Jump to navigation
Jump to search
→Service
| Line 156: | Line 156: | ||
== Service == | == Service == | ||
The service is implemented as a JavaScript XPCOM component with contract ID | The service is implemented as a JavaScript XPCOM component with contract ID <var>@mozilla.org/content-pref/service;1</var> that implements the nsIContentPrefService interface. | ||
=== Core Methods === | === Core Methods === | ||
| Line 179: | Line 179: | ||
=== Getting All Prefs === | === Getting All Prefs === | ||
The getPrefs method allows consumers to retrieve all preferences for a given site: | The <var>getPrefs</var> method allows consumers to retrieve all preferences for a given site: | ||
nsIPropertyBag getPrefs(in nsIURI uri); | nsIPropertyBag getPrefs(in nsIURI uri); | ||
The method returns an instance of | The method returns an instance of <var>@mozilla.org/hash-property-bag;1</var>, which implements both the nsIPropertyBag and the nsIPropertyBag2 interfaces. Bag keys are preference names, while bag values are preference values. | ||
=== Observers === | === Observers === | ||
| Line 192: | Line 192: | ||
void removeObserver(in AString name, in nsIObserver observer); | void removeObserver(in AString name, in nsIObserver observer); | ||
When a pref changes, the service notifies observers via the | When a pref changes, the service notifies observers via the <var>content-pref-changed</var> topic. | ||
<strong>What's the right name for this topic?</strong> | |||
The notification is similar to the one nsIPrefBranch2 sends with the <var>nsPref:changed</var> topic, but it has two key differences: | |||
* nsIContentPrefService takes only an exact preference name (nsIPrefBranch2 permits a consumer to watch an entire preference branch by passing in a branch prefix like "foo.bar.") | * nsIContentPrefService takes only an exact preference name (nsIPrefBranch2 permits a consumer to watch an entire preference branch by passing in a branch prefix like "foo.bar.") | ||
| Line 201: | Line 205: | ||
** newValue: the new value of the preference. | ** newValue: the new value of the preference. | ||
<strong>Should the service support preference branches?</strong> | |||
<strong>Should the service pass a custom component with a custom interface (like the LiveTitleNotificationSubject component with the nsILiveTitleNotificationSubject interface) instead of a property bag?</strong> | |||
<strong>Is there any use for the notification's data parameter?</strong> | |||
=== Groupers === | === Groupers === | ||
Groupers are components that categorize URIs into | Groupers are components that categorize URIs into sites. They implement a simple interface, nsIContentURIGrouper: | ||
readonly attribute AString name; | readonly attribute AString name; | ||
| Line 216: | Line 220: | ||
The name attribute is an arbitrary identifier for the grouper that the service uses to associate a preference in the database with the grouper responsible for determining its group. The group method returns the name of the group to which a given URI belongs. | The name attribute is an arbitrary identifier for the grouper that the service uses to associate a preference in the database with the grouper responsible for determining its group. The group method returns the name of the group to which a given URI belongs. | ||
<strong>Should we just use the contract ID as the arbitrary identifier for the grouper, and how do we retrieve that from an instance of the component? Note: this attribute is only necessary if we want to store groupers in the database.</strong> | |||
The default grouper categorizes URIs by effective TLD + one additional hostname segment (i.e. example.com or bbc.co.uk). | The default grouper categorizes URIs by effective TLD + one additional hostname segment (i.e. example.com or bbc.co.uk). | ||
<strong>Should the default grouper categorize URIs by entire hostname?</strong> | |||
The service implements an attribute representing the grouper it uses to extract a site from a URI: | The service implements an attribute representing the grouper it uses to extract a site from a URI: | ||
| Line 230: | Line 230: | ||
attribute nsIContentURIGrouper grouper; | attribute nsIContentURIGrouper grouper; | ||
The attribute is read/write so that extensions can change the way URIs get grouped. | The attribute is read/write so that extensions can change the way URIs get grouped by setting this attribute. | ||
<strong>Would it make more sense for this to be read-only and for the service to use the grouper specified by an application-wide preference?</strong> | |||
== Controller == | == Controller == | ||