Re: How to control the commit of text edit field with binding?
Re: How to control the commit of text edit field with binding?
- Subject: Re: How to control the commit of text edit field with binding?
- From: mmalcolm crawford <email@hidden>
- Date: Sat, 6 May 2006 10:23:14 -0700
On May 6, 2006, at 4:29 AM, Dustin Voss wrote:
On 6 May 2006, at 1:54 AM, mmalcolm crawford wrote:
... why not just let the object controller manage its own object
-- a dictionary, or a temporary instance of the correct class?
Well, you mention validation. And, personally, I prefer keeping the
number of strings floating around -- in this case dictionary keys
-- to a minimum.
Its not clear what the relevance is here. You're using bindings.
You're using KVC. You already have strings.
I think I'm trying to swim against the tide on that, though.
Finally, there might be a need to use older outlet-based tricks,
which would be hard to do if the outlets are dictionary values. :)
It's not clear what "tricks" you might have to do that require
outlets? Moreover, in general UI elements should always be bound to
NSController instances so that you benefit from the functionality
they provide.
No, you could use bindings is you use the key-path 'self'.
Ah, I was not aware of this key-path. Where is it documented?
<http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
ObjC_classic/Protocols/NSObjectProtocol.html#//apple_ref/occ/intfm/
NSObject/self>
But in your case, involving defaults, you probably want to keep
the settings in a dictionary anyway to map setting to value. So
just make the dictionary a property of the window controller, and
bind NSObjectController's contentObject binding to that
dictionary. Then each control's content can be bound to the
actual user default key through the NSObjectController.
No, if you're using NSUserDefaultsController, use the API it
provides.
What I am suggesting is an alternative to NSUserDefaultsController.
Since NSObjectController is taking on the controller role here,
there is no reason not to use NSUserDefaults.
NSUSerDefaultsController already provides API to do exactly what's
required. It's not clear why you would want to complicate things by
introducing another controller?
Of course, it looks like James B. has already implemented an
NSUserDefaultsController-style solution... but my suggestion is a
way for other OK/Cancel-type dialogs to use bindings.
Again, if you want to do this it would be better to interpose a
temporary proxy object and an NSObjectController instance.
You still have to copy defaults from NSUserDefaults to your
dictionary, and vice versa, but that is easy. Just make an array
of the user default keys of interest and loop through that to set
your dictionary, and to copy the other way, loop through the
dictionary's keys to set the corresponding NSUserDefaults entry.
No, if you do ever need to update an object using a dictionary,
use the API key-value coding provides:
<http://developer.apple.com/documentation/Cocoa/Reference/
Foundation/ObjC_classic/Protocols/NSKeyValueCoding.html#//
apple_ref/occ/instm/NSObject/setValuesForKeysWithDictionary:>
I don't believe that NSUserDefaults is KVC compliant. I don't see
that it implements valueForKey: or setValue:forKey:. If it is KVC-
compliant, the API you linked would obviously be better.
I misunderstood what you meant. It's not clear again why you would
start using NSUserDefaults directly instead of
NSUserDefaultsController. In the latter case, you can update
'values' using setValuesForKeysWithDictionary:. And if you're using
a proxy dictionary to store values until an OK button is pressed,
then it's easiest to update the target object's values using KVC.
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden