Talk:JavaScript Preferences Class

Regarding default values for prefs

There's a concept of Default preferences in Mozilla prefs system. I really like it and prefer using it over using methods like get*PrefDef(aPrefName, aDefaultValue) (that is, wrapping calls to prefs XPCOM in try { } catch blocks or checking value type), because:

1. All default values are in one place, where they can easily be reviewed and changed.
   • In particular, if you read a pref in two different parts of code, you don't have to duplicate default values, as you would have to, if you were using get*PrefDef.
2. The prefs read from 'defaults' files are displayed in about:config, helping power users to find "hidden" prefs.
3. Support for locked prefs - for free.

When using 'defaults', wrong type of a preference or anything else that makes get*Pref method of nsIPrefBranch fail, is an exception and should be handled as such instead of just silently putting a hard-coded default value there.

asqueella

Hi Asqueella, How does an extension install default preferences? I was trying to solve the problem which arises when default preferences do not exist.

grimholtz

for toolkit apps just put it into xpi/defaults/preferences/whatever.js

more info here

asqueella

OK, I understand now. One question. In private email, I thought you criticized my use of a 2nd argument in the preferences wrapper ::functions which was used as the return value if the getters() failed due to incorrect type and/or the preference does not exist. ::However, I read on your site "All of them take two parameters, the pref name and the default value, which is returned if an error ::(such as, the pref, that code tried to read, did not exist or had incorrect type) occurs."

Isn't this exactly what I was doing in PrefsWrapper.js?

grimholtz