Bindings and nested preferences
Bindings and nested preferences
- Subject: Bindings and nested preferences
- From: Andy Klepack <email@hidden>
- Date: Tue, 16 Jun 2009 10:25:12 -0700
- Acceptlanguage: en-US
- Thread-topic: Bindings and nested preferences
I'm curious about what patterns exist for binding to nested sets of preferences such as a dictionary value at the top level of the user defaults. I've seen a couple of questions similar to this, but no one appears to have received the definitive answer.
My scenario is that I have an application with several distinct modules and I would like each module's preferences to be stored in a separate dictionary.
Say the user defaults look like so:
{
module = {
moduleValue = "xyz"
}
}
The module has a nib with a text field that should be bound to the moduleValue. I'd like to have it bind to sharedUserDefaultsController.values.module.moduleValue. As far as I can tell this is not valid. The bindings system thinks that 'module.moduleValue' is the key in the user defaults to bind to.
My second approach was to create an NSObjectController for which the content was bound to sharedUserDefaultsController.values.module. I then bound the text field to objectController.moduleValue. In this case there were problems when the module dictionary did not already exist (the object controller's content was null), plus whenever the value moduleValue was set it didn't trigger any user defaults behavior since it was a modification of nested content and thus didn't trigger change notification for defaults themselves.
The most obvious solution is to create a custom object (ModuleController) for the nib, create a moduleValue property with custom accessors, implement those accessors to interact with the user defaults, and then bind the text field to those properties. At the same time, that seems pretty code intensive for something I suspect is a fairly common design.
Am I way off track here? Is there a pattern that others have found to be useful?
Many thanks,
-Andy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden