Re: Binding to an NSArrayController however binding is 1-way only.
Re: Binding to an NSArrayController however binding is 1-way only.
- Subject: Re: Binding to an NSArrayController however binding is 1-way only.
- From: Ken Thomases <email@hidden>
- Date: Thu, 18 Sep 2008 05:44:32 -0500
On Sep 17, 2008, at 10:25 AM, dreamcat7 wrote:
I am stuck finding a solution for my array of arrays problem. - A
problem with a twist !
Quincy Morris has already explained that
bind:toObject:withKeyPath:options: doesn't do what you guessed it might.
Here's how I would explain it (after being a participant in a couple
of previous in-depth discussions about it): NSObject's default
implementation of the bind:toObject:withKeyPath:options: method has no
clearly defined semantics. Any class which wishes to support bindings
should define the semantics of their own bindings. The Cocoa classes
which define bindings document their semantics in the Cocoa Bindings
Reference <http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/
>. Any other class, including your own, would have to override
bind:toObject:withKeyPath:options: and determine through its
implementation what semantics it should have.
That said, I wanted to address a couple of other issues I saw with
your question:
1) If you for some reason find that using bindings with NSTableView is
too restrictive, you might want to think about falling back to the pre-
bindings way of populating a table view: the data source.
2) You seem to be hung up on the internal representation of
properties. Although I didn't quite follow exactly what you're trying
to do, you seem to be of the belief that you have to use
NSMutableArray for a mutable to-many property. This is incorrect. A
to-many property doesn't require any particular kind of backing
storage. If you implement the to-many indexed accessors, you can make
a to-many property that works however you like under the hood. The
indexed accessors for to-many properties are documented in the Key-
Value Coding Guide <http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html#//apple_ref/doc/uid/20002174-178830-BAJEDEFB
> and also in the comments at the declaration of -
mutableArrayValueForKey: in NSKeyValueCoding.h. (Sadly, the
documentation for that method doesn't seem to be correct/complete.)
So, your "synthetic" dates and emails arrays don't need to be
implemented in terms of a backing NSMutableArray and bindings (or
KVO). They can exist solely as the requisite accessor methods, which
can then compute their value based on other model data (or whatever).
This can be used to present multiple "flat" to-many properties from a
single array of multi-property objects. Although, I'm confused about
why you want to do that. I don't see it as providing any advantage to
you.
Similarly, you expressed concern about exposing the implementation of
your Items class. Well, of course, you don't have to expose that.
That's what properties are for -- they are an interface-level aspect
of your class and need not expose anything about its implementation.
With KVC and KVO, you can even access properties without seeing the
interface declaration of the object in question.
3) You seem to be building a model which is based on an
NSArrayController. (I.e. you tried to make your dates and emails
properties by binding through the controller's arrangedObjects
property.) This gets things backwards. Your model should not have
any dependencies on your controller(s).
It's possible that I misunderstood. Perhaps dates and emails are
properties of your coordinating controller which you intend to be a
synthesis of values from your model. That's OK. However, if you do
that, then you still shouldn't base it on an NSArrayController. It
should be based directly on your model plus some controller-level
logic. Then, an NSArrayController could be built which presents that
synthetic property to your view layer.
In my opinion, a coordinating controller should not depend upon a
mediating controller. It should be the other way around.
Cheers,
Ken
_______________________________________________
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