Paul Sandoz wrote:
> Been thinking about how to improve the preferences
> related behaviour/usage of the address book with a
> view to rewriting the nsDirPrefs.cpp code.
Actually I am not using nsDirPrefs.cpp to store the directory
preferences.
I am writing JS code to save preferences.
> Still not sure of the best way to ensure that
> manipulation of address books and associated
> preference properties is consistent and unified.
>
> It is probably not a good idea for the 'abdirectory'
> data source to listen for preference changes because
> multiple callbacks will be occur for a newly created
> address book entry which contains many property entries.
>
> Only solution may be to go through the 'abdirectory'
> RDF data resource or data source.
>
>
>
> o Should not have to deal with old style preferences
> e.g. ldap_1, and perform migrating. This should
> be in separate code and run once when required.
I believe these preferences have already been migrated.
>
> o Address book types can be defined by the 'uri'
> property.
Other than having a dirType preference how can we put it in the uri?
Atleast for directory servers we cannot put it in the url.
> - Should always be present in the preferences
> either as default or in the prefs.js.
> - May also result in a reduction in the
> number of properties for an address book
> depending on what and how much information
> the uri can represent.
> - Means that properties such as 'type' and
> 'filename' become redundant.
>
> o For account specific directories there needs to be a
> related property that is a reference to the account
> in question.
We are saving this preference per identity.
e.g. mail.idenity.id1.directoryServer
>
> - The property name:
> 'address.servers.ab5.mail.account'
> could have a value of:
> 'account1'
> Thus mail account properties are defined
> by appending the property name and value:
> 'mail.account.account1.*'
I think this is a good idea.
>
> o The property name schema for representing address books
> could be changed to be more general and meaningful.
> - The schema is currently:
> 'ldap_2.servers.<unique name>.*'
> Since there will be address books of different type
> the 'ldap_2' could be changed to 'address':
> 'address.servers.<unique name>.*
If we want to do this we need to change the preferences we already have
for adressbooks. And also we need to change the ldap_2... preferences
that we migrated from 4.x. I think we should get input from Candice on
this.
>
> - Should the 'ldap_2.servers' be retained for
> ldap specific properties and then an address
> preference entry could reference a certain
> ldap entry?, much in the same manner as an
> account specific address book.
> o We have modified the nsIAbDirectory.createNewDirectory
> to take an array of property names and values which
> are strings and wstrings respectively. The 'abdirectory'
> implementation is responsible for creating a new entry
> in the preferences. The trouble is that type information
> is lost because every value is treated as a wstring :-(
> - Could do automatic conversion to int and boolean.
> I think this could work as long as there are no
> complex types, but may not be extensible in the
> future.
> - Could have method which takes an nsIPrefBranch
> attribute which points to the newly created
> address book entries.
>
> o The directory factory interface can have an
> additional method to create instances from a
> branch entry in the preferences using the
> nsIPrefBranch interface.
> - The nsIPrefBranch.idl has recently been
> updated is looking alot cleaner than the
> nsIPref.idl
I agree, nsIPrefBranch is lot cleaner.
I am not sure nsIPrefBranch is turned on by default in the build right
now, but I believe in the near future it is going to be.
