On Apr 2, 2014, at 7:34 PM, Roland King <r...@rols.org> wrote: > > 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.
Apple’s documentation isn’t always perfect. Though it’s far from the worst I’ve seen, it does lack a bit in areas. > > 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/sevenbitstech%40gmail.com > > This email sent to sevenbitst...@gmail.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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