Re: Displaying two different sub-entities in one table view
Re: Displaying two different sub-entities in one table view
- Subject: Re: Displaying two different sub-entities in one table view
- From: Quincey Morris <email@hidden>
- Date: Fri, 5 Mar 2010 11:18:34 -0800
On Mar 5, 2010, at 10:04, Jean-Henri Duteau wrote:
> I have a Team that has Skaters and Goalies. Skaters and Goalies have Player as a parent. Team has a to-many relationship to Player. I have a TableView that displays all of the players of a selected team. Everything works just fine as long as I restrict myself to attributes that are only on the Player object. But I want to display Skater attributes and Goalie attributes. There is an additional wrinkle that the attributes are located off a Ratings object attached to each Player. A Skater has a SkaterRatings object while a Goalie has a GoalieRatings object.
The difficulty is that (of course) all the rows in a table view are the same. Therefore the table view must see a consistent data model that isn't your actual data model.
One way of doing this would be to define all of the properties that the table view needs in the Player parent entity, and to override the appropriate ones in the Skaters and Goalies entities to return the correct value.
Another way of doing this is to define a set of (non-Core Data) intermediary objects that have the desired "display" properties, and keep these in sync with the actual data model via KVO.
It's hard to be more specific without knowing how you intend to represent different properties that are row-wise different in a table where all the rows have the same structure. What do you show for a Skater-only property in a Goalie row?
> I've tried a number of different ways to make this happen. I *think* that I may need to produce a custom TableViewDataSource and I tried to do this with the content backed by an NSArrayController, but I couldn't make that work.
A data source is easier in some ways -- it doesn't require that your data model objects have a consistent set of properties, just that you're able to generate a consistent set of object values from the data model -- but it doesn't fundamentally change the problem.
IMO, using an array controller like this is a terrible idea. Array controllers are mostly view-supporting objects, and integrating them into your data model code is a bit messy. Just go straight to your data model properties. If you need sorting and filtering, use Core Data's capabilities directly. I can't immediately think of any other reason why it might seem to be a good idea to use an array controller here.
Couldn't make that work in what sense? What went wrong?
_______________________________________________
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