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

Attachment: 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

Reply via email to