On Apr 2, 2014, at 7:54 AM, Roland King wrote: > I have an array property in my model which is a list of serial devices, I > want to display it in a table view and let the user select one. So I > instantiated a tableView, an NSArrayController, bound the contents of the > NSArraycontroller to the serialDevices property and added a few other > bindings to the Table View and Table View Column; OK now I have a list of > devices on the screen. > > In the model I had a selectedSerialDevice property, which was the selected > object out of the serial device array, I wanted to bind that to the selection > on the table view. I could find only a Selection Indexes binding on a Table > View so I changed the model to have an NSIndexSet with one index representing > the selected serial device, which I bound through the NSArrayController and > then to the table view. So already my model isn't actually what I wanted, I > wanted a selected object, but the NSArrayController and table View want an > index set so now my model has an index set in it to make the other objects > happy. The view/viewcontroller is driving the model .. hmm. > > At this point I realized the NSArrayController was doing nothing. It was > forwarding my array of objects and my selected index set I didn't want to the > Table View. I took it out and bound direct to the equivalent properties on > the model, everything continued to work. My array shows, I select an object > and the index set I didn't want is updated in the model. > > So that led to two questions > > 1) What is the point of the NSArrayController? It mirrors the bindings on the > Table View so it really seems to do nothing. If it were smart and converted a > model property like .. selected object into the index set the table view > wants, that would be useful, that would be what I'd usually use a Controller > for, to turn model-speak into view-speak, but it doesn't, it just passes > through.
Because you get a certain amount of functionality "for free". Go ahead and try to sort your table view without an NSArrayController and see what happens... > 2) Do I really have to change my model to present an index set for > 'selection' because there is no standard controller object which can turn > objects/selected object into something a table view can use? No. You could subclass NSArrayController to provide your own selected object binding. It's not the API's job to provide every possible behavior you would ever want to use, nor to provide such. It would make for a rather unwieldy API. I suspect, however, that there is a good performance reason to not have a selected object binding, as the NSController classes staunchly avoid it. > I thought bindings were supposed to remove the need to write glue code to > match a model to a view, they do .. if the model matches the view .. in which > case the NS*Controller objects don't actually do much. Not really--bindings are supposed to help remove the glue code to *synchronize* your model and your view. You could always switch over to using the table view data source methods (and don't forget handling when data changes in the model and/or view) and see if those are easier--then you will have a more accurate basis of comparison.... Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
