Re: Binding to a view's model object
Re: Binding to a view's model object
- Subject: Re: Binding to a view's model object
- From: Keary Suska <email@hidden>
- Date: Sun, 25 Jan 2015 20:50:21 -0700
On Jan 25, 2015, at 6:07 PM, Roland King <email@hidden> wrote:
>
>> On 25 Jan 2015, at 23:15, Keary Suska <email@hidden> wrote:
>>
>> On Jan 25, 2015, at 3:34 AM, Roland King <email@hidden> wrote:
>>
>>> I have a xib with a top-level view and a bunch of subviews which represents one view of a given model object. The top-level NSView subclass has a readwrite property which is the model object of which it's a view. I thought this was a pretty standard pattern, especially in OSX which only just recently started to really make use of view controllers.
>>
>> There is nothing standard about this pattern. It is not, AFAIK, a pattern at all, but an anti-pattern. Previous to a view controller the only "view" controller was a window controller, and finer grained control was necessary. For this very purpose it is the view controller, and not its view, which tends to "hold" the model object. Hence Xcode is balking at your attempts.
>>
>
> And yet I was certain I'd stolen it from somewhere, and woke up remembering where. NSTableCellView, is a view, has an objectValue property. When you drag an NSTableCellView into IB and add subviews to it, the bindings inspector dropdown for those subviews includes the table cell view, called something like XXX Cell View. So you bind to 'XXX cell view' with path 'objectValue.someProperty'. The NSTableCellView is really the VC and objectValue is the model object.
Of course--in this case, NSTableCellView is really just acting as an intermediary for its subviews. In a way, the subviews are really binding *through* NSTableCellView , although it is hiding those implementation details. That may be what you are after but it didn't seem to be what you were describing.
> What I have is a direct rip off of that pattern. I've embedded a stack view in a class and given it a datasource which serves up NSView subclasses for an item at a given index, you can register a nib against an identifier and ask the class to create you a new view or give you a reused one. The method names are even stolen pretty much straight from NSTableView. It's like an NSTableView or a NSOutlineView in usage, just uses a stack view under the hood (because stack view uses autolayout and this makes dynamic row sizing etc super easy when you have rows which use autolayout). IB however knows about NSTableCellViews and adds them into the bindings inspector dropdown for their subviews, it doesn't know about my top-level view class, RKStackCellView, and doesn't.
>
> I can add them in awakeFromNib pretty easily, do in code what IB does for NSTableCellViews graphically, or I could change my datasource method from returning an NSView*, like NSTableView's does, to returning a view controller, and then keep track of the VCs and their associated views in my stack view using class, as the stack view only wants the NSView but I'd need to keep the VCs referenced somehow to stop them being deallocated. I'll try them both, see which one I like best.
You can do what you want, you would just have to manage the bindings programmatically. It still seems easier to me--and possibly saner--for each view to have a VC that holds the model, and to which the subviews are bound.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden