Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
- Subject: Re: Bug in NSArrayController? (immutable instead of mutable dictionaries)
- From: Uli Zappe <email@hidden>
- Date: Fri, 22 Oct 2004 15:22:28 +0200
Am 22.10.2004 um 06:30 schrieb Scott Anguish:
OK, maybe you're right and it's a documentation bug, because
NSUserDefaultsController says nothing about changing mutable to
immutable.
I thought this was documented, but it doesn't seem to be. I've filed
a bug.
Good. This should definitely be pointed out very clearly because it's
definitely not what you would expect from a usability point of view.
Note that even if it were documented that NSUserDefaults returns
immutable objects, that *does not* imply that a Binding to
NSUserDefaultsController changes the mutability of the objects in the
bound container.
I think this is likely due to a KVC issue where an entire array is
being replaced because indexed accessors isn't available.
The problem is that Bindings work beautifully if they work out of the
box, but if they don't you're easily caught up in the "behind-the
scene" magic.
I think what I was trying to implement is an absolute standard
situation when dealing with user defaults. Take Mail.app as an example;
you have the simple "global, 1:1" preference settings such as "Fonts &
Colors" which you can implement with Bindings exactly the way that's
described in Apple's "Binding Your Preferences in Cocoa", but you also
have the preferences for each specific mail account. To implement the
latter, you *must* bind the controller views to an NSArrayController
with *mutable* dictionaries first, and then bind this content array to
the user defaults controller.
As I said, while a bit more complex, I think that's also an absolute
standard case for implementing defaults, and since that's an area where
Bindings shine, Bindings should really work out of the box here. But
they don't. That they make your defaults dictionaries inadvertently
immutable is contra-intuitive, to say the least.
To better this situation, Apple should at least:
1. make this problem very clear in the documentation for
NSUserDefaultsController
2. add a respective example to "Binding Your Preferences in Cocoa",
which should also point out that it is crucial for this to work at all
that you *must* check the "Handles Content as Compound Value" option in
the NSArrayController's Bindings Info - something I never would have
guessed from the description of this option in the docs
3. provide a factory value transformer that transforms immutable arrays
of immutable objects to mutable arrays of mutable objects (yes, that's
not hard to do yourself, but it shouldn't be necessary to do again and
again given that this is a standard situation - actually, the very
reason that such a transformer does not exist in Cocoa made me believe
for quite some hours that this just can't be necessary for my
implementation to work since it's such a standard task I'm
implementing.)
IMHO, a binding should *never* do that, and it is a real showstopper
for this technology because it can lead to all kinds of problems. So
I think you could very well argue that no matter how NSUserDefaults
behave, NSUserDefaultsController should take care to only return
mutable objects to NSArrayController if NSArrayController's class
object is mutable.
there is no two way communication there...
Well, it is. All I do is to add a new (mutable) dictionary to
NSArrayController's content array. Then NSArrayController sends it's
array to NSUserDefaultsController and immediately gets it back as an
immutable variant with which it replaces its original. This happens all
at once, so that in effect it looks as if NSArrayController created
immutable dictionaries from the beginning. If that's not a two way
communication, I don't know what is ...
Bye
Uli
________________________________________________________
Uli Zappe, Solmsstraße 5, D-65189 Wiesbaden, Germany
http://www.ritual.org
Fon: +49-700-ULIZAPPE
Fax: +49-700-ZAPPEFAX
________________________________________________________
_______________________________________________
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