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 (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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to