On Jan 25, 2015, at 6:07 PM, Roland King <r...@rols.org> wrote: > >> On 25 Jan 2015, at 23:15, Keary Suska <cocoa-...@esoteritech.com> wrote: >> >> On Jan 25, 2015, at 3:34 AM, Roland King <r...@rols.org> 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 (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
