>> On Oct 18, 2010, at 10:22 AM, Trygve Inda wrote: >> >>>> So if the master dictionary and the array for the NSTable are >>>> encapsulated together in a class, you could use NSMutableArray as the >>>> primary structure, and encapsulate a hidden NSMutableDictionary used >>>> only for faster searching. Both are maintained in parallel by the >>>> enclosing class, so there's never any need to ask the dictionary for >>>> its array of values, nor to copy an immutable array to make a mutable >>>> version for table insertion. In short, make a class that >>>> encapsulates all the desired behavior by itself, rather than using a >>>> naked dictionary and the supplementary arrays it makes. >>> >>> How would I go about doing this and still bind to my NSArrayController? >>> >>> I'd have a (singleton) class MyDataClass with two instance vars: myArray and >>> myDictionary both of which would hold the same objects and both would be >>> mutable. >>> >>> So when I bind the NSArrayController to myArray, and the user adds an item >>> via the table (and thusly the add: of NSArrayController), how will my class >>> know that it needs to also add it to the myDictionary? >> >> You are mistaking instance variables for properties. Instance variables are >> implementation details, and nothing outside of your class should be aware of >> them. >> >> Properties are part of your interface, essentially the accessor methods and >> their behavior. (Remember that you can have properties that are not backed >> by >> instance variables.) >> >> So, you should be thinking in terms of writing accessor methods which present >> a consistent view of the to-many relationship (which happens to be backed by >> an array and a dictionary). Look up the indexed accessor pattern for to-many >> relationships in the KVC documentation >> <http://developer.apple.com/library/mac/documentation/cocoa/Conceptual/KeyVal>> u >> eCoding/Concepts/AccessorConventions.html#//apple_ref/doc/uid/20002174-178830>> - >> BAJEDEFB>. Also, take a look at "Managing a non-array collection, and >> filtering" on mmalc's page of Cocoa examples >> <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>. >> >> To keep yourself honest, and to help you learn, try making this to-many >> relationship property have a name completely different from the names of the >> instance variables which back it. Also, I generally recommend that all of >> one's own classes should override +accessInstanceVariablesDirectly to return >> NO. (I regard KVC's ability to bypass your interface and directly access >> your >> instance variables as A Bad Thing™.) > > Yes, I meant properties... > > I guess I am just not seeing how my NSArrayController would ties to this. So > I have a class MyDataClass and since my NSTableView is tied to an > NSArrayController, then the NSArrayController needs to get it's data from > MyDataClass. > > So is there then a myArray property in MyDataClass that the > NSArrayController binds to? > > Or does NSArrayController somehow bind to a non-array property, but one > that responds as if it were an array? > > Is there any sample code of this sort of set up?
I was able to get the mmalc sample but even that shows the contents of the NSArrayController being bound to a NSMutableArray... Not how to bind it to some arbitrary class. T. _______________________________________________ Cocoa-dev mailing list ([email protected]) 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]
