On Sep 17, 2010, at 12:16, Martin Wierschin wrote: > I am binding to the shared NSUserDefaultsController in IB, not NSUserDefaults > directly.
I doubt Ken really thought you were binding to anything other than NSUserDefaultsController. He was really elbowing me, correctly, for having said something stupid. > But adding a category to the controller for individual default properties > won't work, because the controller just passes the validation on to > NSUserDefaults (or at least it should). > > If everything behaved as I expect, when the controller is asked to validate > the key path "values.mySpecialProperty", the defaults should in turn be asked > to validate the key "mySpecialProperty". The trouble is that at no point do > either of these classes try to dispatch -validateMySpecialProperty:error: to > any instance. In fact, NSUserDefaults never even receives > -validateValue:forKey:error: There's no "should" here (in "the defaults *should* in turn be asked..."). The mechanism we're discussing is KVC validation. Under that mechanism, it would be the object that *has* the properties -- namely [NSUserDefaultsController values] -- that would do the validation, but since it's a private proxy object there's no way for you to add validation to it. The proxy object can't "dispatch" KVC validation to the NSUserDefaults object because, as we already established, NSUserDefaults isn't KVC compliant. So, the issue isn't really KVC validation, but that NSUserDefaults doesn't implement any kind of validation mechanism at all. If it did, then presumably the [NSUserDefaultsController values] proxy's KVC validation could delegate to NSUserDefaults' validation, however that was implemented. Filing a bug report asking for a validation mechanism for NSUserDefaults seems perfectly reasonable. I can't imagine, though, that Apple would be enthusiastic about providing a mechanism that depended on adding methods via a category. Perhaps something involving Blocks would make sense. Note, however, that there is a small problem with this in the general case -- it's possible for the NSUserDefaultsController to hold (unsaved) values that are different from the NSUserDefaults values, when 'appliedImmediately' is NO. That implies that the proper place for validation is within NSUserDefaultsController's private ecosystem, not that of NSUserDefaults._______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
