> 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/KeyValu > 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? T. _______________________________________________ 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 arch...@mail-archive.com
