[Dev] persisting a preference

[Alec Flett]

I think there's something to be said for exploring a somewhat generic 
preferences architecture, or at the very least a set of conventions - 
duck typing for preferences if you will (if it looks like a preference, 
and acts like a preference, its probably a preference)

In the mozilla project (full disclosure: I was the owner of the 
preferences backend) we developed a system where all prefs are stored in 
a central place, and each pref has its own name within the a private 
namespace, such as "browser.cache.memory.enable". 3rd party 
plugins/extensions can "register" new prefs. This allows for a 
particularly useful feature in mozilla, 'about:config' - go ahead - type 
this into the URL bar in FireFox. What you'll get is a UI to edit all 
global prefs across the system. Neat, huh?

However, I personally don't think that kind of system is quite 
appropriate for a project like ours, especially given the dynamic nature 
of both python and the repository.. but there are a few things about the 
mozilla prefs system that were useful specifically for preferences:
1) a global list of 'all preferences' so that they could be reflected 
into the UI dynamically like about:config.
Of course, all of our repository can be reflected into the UI, but I 
think there is value in distinguishing those values in the repository 
that give some obvious, useful, and predictable change in the behavior 
of the application.
2) the ability to register for changes to a preference, or a set of 
preferences. This is useful because any one of a number of actions could 
change the value of a preference, not just a preferences dialog box.
For instance, you can register a callback for when the value of 
"network.protocol-handler.external.mailto" changed, or for 
"network.protocol-handler.external.*" to capture all sub-changes.

Both of these features are almost trivial given the repository.

I like philip's PrefsForMyParcel, and in fact I think we could 
accomplish most of 1) and 2) by making a base Kind/class, ParcelPrefs 
(or something..maybe just 'Preferences') that each parcel could derive 
from, and declare new schema attributes to store individual preferences. 
The KindCollection for ParcelPrefs would then be the 'registry' of all 
prefs in the system.

the only trick at that point is the notification when preferences 
change... but we have a number of systems for notifications, so I'm 
willing to bet that would be fairly easy and we can address it when 
there is actually a need.

Alec


Phillip J. Eby wrote:
> At 08:57 PM 11/2/2005 -0800, Jeffrey Harris wrote:
>> Hi Folks,
>>
>> What's our current thinking on how a developer should go about
>> establishing and using what I'll call a preference, essentially a single
>> persistent value with a well-known name (in this case, I'm wanting to
>> persist the last directories chosen for import and export)?
>>
>> We've got lots of well-known collections living in
>> parcels/osaf/app/__init__.py, perhaps that's the appropriate place for
>> preferences?  It doesn't feel quite right to me...
>>
>> I'm sending this question to the list instead of asking one person or
>> another because
>> A) I think there might be different opinions, and
>> B) I'm hoping someone will write up a detailed example so that knowledge
>> can live on in the list, not just my brain :)
>
> The simplest thing that would work:
>
>     class PrefsForMyParcel(schema.Item):
>          some_pref = schema.One(sometype, defaultValue=something)
>          # ... other preferences
>
>     def installParcel(parcel, oldVersion=None):
>         PrefsForMyParcel.update(parcel, "prefs")
>
> Accessing preferences can then be done via:
>
>     schema.ns("my.parcel", view).prefs.some_pref
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev