[Dev] persisting a preference
Alec Flett
alecf at osafoundation.org
Fri Nov 11 12:18:20 PST 2005
Phillip J. Eby wrote:
> The reason for #2 is to support upgrading; when a new version of a
> parcel is loaded, all the values set in installParcel() will override
> any existing values, thus wiping out the preferences. And, since
> initialValue settings are only applied when an item is created, an
> upgrade that adds new preferences will find the preference data
> missing from the preferences item.
>
+1 to this idea, I think I must have glossed over that in your last post.
(This is actually how we did it in mozilla as well - the default value
was stored internally as a part of the app, and only used as backing for
when the user's preference wasn't already set - that's why some
preferences are bold in about:config - those are the ones that have a
'local' or user-set value)
Alec
> By contrast, a preference attribute's 'defaultValue' will always be
> seen if no value has been specifically assigned to the attribute.
> This also means that when an upgrade occurs, we can change the default
> setting for a preference, and it will apply as long as the user has
> never changed the original setting. For example, if we have a "theme"
> preference, and the user never changes it, then when we change the
> default theme in an upgrade, the new default theme will automatically
> be selected.
>
> Anyway, this is probably more detailed than what you wanted to get
> into right now, but I thought I should mention it for future
> reference. That is, we need to include consideration of what happens
> to preferences during upgrading, even if we decide on a different
> policy than what I'm describing here.
>
More information about the Dev
mailing list