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: Scott Anguish <email@hidden>
- Date: Fri, 22 Oct 2004 16:54:35 -0400
On Oct 22, 2004, at 9:22 AM, Uli Zappe wrote:
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.)
Yes. However, this isn't anywhere near as straight-forward as it
seems. Nor does it really solve the problem.
For handling compound preferences values like this, you're much
better off isolating that editing in it's own NSArrayController that
uses an intermediate mutable collection. That is, when you enter that
'editing state', get the entire array from NSUserDefaultsController,
make a deep mutable copy, and use that with the new NSArrayController.
when you leave that editing state (say, switch to another prefs pane)
you then set the user defaults with that array.
Editing arrays directly from NSUserDefaultsController has all sorts
of issues. If you're saving immediately, you have issues with null
values getting in there, if you provide temporary values to avoid that
you have data that may not be appropriate being KVO'd throughout the
application.
The value transformer idea is a good one, but doesn't work very
well from my experience. you have to use Handles as Compound Value,
which means that you have selection issues that come up.
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 ...
The NSUserDefaultsController doesn't know that the
NSArrayController that it is sending data back to (via KVO) expects
mutability. There isn't a mechanism for that, KVO is a one way
message. So, while it's true that it appears that it is two way, they
are in fact to entirely separate processes. KVC to set, KVO returns
the new value.
_______________________________________________
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