Re: Binding NSTableView columns to dynamic properties in Core Data?
Re: Binding NSTableView columns to dynamic properties in Core Data?
- Subject: Re: Binding NSTableView columns to dynamic properties in Core Data?
- From: Keary Suska <email@hidden>
- Date: Sun, 30 Dec 2012 21:08:39 -0700
On Dec 30, 2012, at 8:35 PM, Rick Mann wrote:
> I'm not sure if this is possible with bindings and Core Data, or how much glue code I'm going to have to write to do this, but I thought I'd ask to see if anyone else has done anything like this.
>
> I want to display a table view with a set of columns that's not known at compile time, but rather at run time. The model has one entity for the rows, and related key-value pair entities for each column in the row. These are generated at run time based on the input data, but they are the same for all rows in a set. Each column may be of a different type than the other, but all the entries in a column are the same.
>
> I suspect I'll have to programmatically build the table columns each time the set changes (not quite sure how to do that, but I assume there are obvious methods for adding and removing columns). Once I'm building the columns, I expect I'd have to programmatically bind them to an NSArrayController. Not sure how I map a key name in a table column through the NSArrayController to my main entity, and through that to the related key-value pair entity. Override the primary entity's valueForKey and have it fetch the related property? Any caveats I should look out for?
It seems to me that the amount of work involved in maintaining the bindings would be more troublesome than simply using data source methods. You would also have much more control as well. I have done basically what you are thinking in the way of a simple database querying UI, where the results would be loaded into a table whose columns are dynamically created to match the columns of a SQL "select" query. Data source is the way to go.
Note, however, that you don't get all of the "free" behavior that NSArrayController gives you for adding objects (especially undo) nor the "free" stuff you get from bindings for cell editing. But it's not hard to code and the managed object context will still maintain undo for you. I still think the build up/tear down of bindings will be more of a pain and more fragile in any case.
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