[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