On 3 Apr, 2014, at 12:22 am, Seth Willits <sli...@araelium.com> wrote:
> On Apr 2, 2014, at 6:54 AM, Roland King <r...@rols.org> wrote: > >> At this point I realized the NSArrayController was doing nothing. ... I took >> it out and bound direct to the equivalent properties on the model.... > > It's not doing nothing. > > The NSArrayController doesn't simply "forward" objects from the model to the > tableview, it has its own copy of the array (the arrangedObjects) which keeps > it separate the model. > > Normally your controller object would have its own copy of the devices array, > be the delegate and data source for the tableview, providing the filtered and > sorted data to the tableview, handle the selection notifications and update > things. Not to mention listen to when the source devices array changes to get > a new copy of it. > > NSArrayController does all of that for you, without interfering with your > model. > > By binding the table view to the model properties directly, you've now > established that no other tableview or any other object can have its own > selection, or order for those objects. You can't sort or filter the tableview > without sorting or filtering the model data itself, which is most often a bad > idea. > > As for the selection property on your model, you can easily listen to either > the tableview or the array controller's selection changing, and set the > property yourself. You're not required or expected to binding everything just > because you can in some manner. > Thanks for the replies thus far - they are making the picture a little clearer. The point about only one tableview being able to have a selection or ordering on the elements is very good, because it's not a use-case I had, I didn't think about it, now I'm wondering how to split the 'list of serial devices' from the 'selected serial device' in a way which works to see if I can (the complication here comes from the act of being selected opening the device and doing stuff and being deselected closes it again, so I need to think on that a bit, perhaps KVO there is better than bindings) I went back to the venerable Cocoa Bindings programming guide and I can see where one of my expectations came from. In the 'Real World Example' under 'What are Cocoa Bindings' is an example of an array of Combatants, bound to a table view, and another table view showing the weapons for that combatant, one of which is selected. That shows various things being bound to 'selection.*', for instance Title is bound to selection.name. That sent me into the documentation to find that indeed there *is* a selected object property on NSArrayController, but it's a *property* not a binding. So I don't need to bind the 'selection' of the NSObjectArray to something, I need to bind something to the selected *property* of the NSArrayController. The asymmetry and different namespace between properties and bindings bites! Well it's nice to know there is such a property, that's what I needed. But there's more. That diagram also shows how the selected weapon flows back to the Combatant (thus meaning a combatant can only have one selected weapon :) ). That binds the property selection.selectedWeapon to a binding called .. selectedObject. Where is that binding? I checked the documentation and can find that on pop up buttons and matrices but not on a table view nor an NSArrayController. That example states it's IB-only, no code required, is it just out of date? If it is, is there a way one could use bindings to accomplish what it's doing there, binding the selected object in a detail array directly back to a property on the selected object in the master? _______________________________________________ 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
