On Oct 5, 2009, at 12:10 PM, Paul McNett wrote:
> But I don't understand the rationale for returning False instead of
> corresponding to the value of the preference. If the stored pref is
> int(0), return False. If it is tuple("apples", "bananas"), return
> True. Etc.
A pref is also a placeholder in the "chain". If I create a pref that
is "dabo.foo.bar", it does not represent a value. I have to assign a
value to it before that happens. The idea is that you can have a base
preference object for your app, and sub-preference objects, and then
fill in their values as needed. Example: your app's BasePrefKey is
"myclient.thisapp". You may want to store font prefs, and maybe some
grid prefs, and maybe another custom section that I can't think of
right now, so your app would create references to
"myclient.thisapp.fonts", "myclient.thisapp.grid", and
"myclient.thisapp.custom". None of these represent values; they are
merely paths.
In your preference settings, you will want to bind your controls by
setting DataSource to the path, and DataField to the particular
value's name (e.g., "font_face"). Now changing the UI updates the
preference, and vice-versa.
> I guess I don't get the 'lack of value' argument. Pref objects store
> values (or as the case may be, lacks of value). A dot-separated path
> is
> a value, no?
No, it could simply be a path to an empty pref object.
> Shouldn't __nonzero__ simply return bool(the_value)?
Again, no. Think of the example above:
myclient.thisapp.fonts == a dPref object
myclient.thisapp.fonts.font_face == a string (e.g., 'Courier')
The first is "empty", in that it does not contain a value. The second
is not empty, as it is a string of non-zero length.
> if self.DataSource is not None
>
> should be sufficient, and would keep similar problems from happening
> with other non-dPref objects.
No, because it could also be an empty string. And there really aren't
any other objects that behave like dPref does. You need to really work
with them to understand how they are supposed to behave. This is one
of those cases where the "magic" is entirely worth it, as it makes
preference handling extremely simple to the developer. This issue was
one of the edge cases that I missed because I always had Web Update
off on my machine, due to working with a source control-managed copy
of Dabo.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message:
http://leafe.com/archives/byMID/[email protected]
