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 (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 [EMAIL PROTECTED]
