• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Displaying two different sub-entities in one table view
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Displaying two different sub-entities in one table view


  • Subject: Re: Displaying two different sub-entities in one table view
  • From: Jean-Henri Duteau <email@hidden>
  • Date: Fri, 5 Mar 2010 11:48:27 -0800

On 2010-03-05, at 11:21 AM, Quincey Morris wrote:

> 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.
>

I know and I'm trying to think of UI alternatives that wouldn't smell as badly as this one does.

> 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.
>

Yeah, that's the easiest but I grimace when I think of that.

> 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.
>
I thought of that too. :)


> 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?
>
Just empty fields, i.e ""

> 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.
>
I didn't mean to imply that I'm integrating an array controller into the data model.  I'm not doing that at all.  The reason for creating a TableSource backed by the Array controller is to get the "off-the-shelf" capabilities that NSArrayController gives you in IB.

> Couldn't make that work in what sense? What went wrong?
I didn't try very hard - just an hour or two this morning, but I couldn't get my tableView:objectValueForTableColumn:row: method to be called.  The numberOfRowsInTableView: got called so I think I had hooked it up right.  But as I said, I didn't try very hard.

In any case, thanks for the thoughts.  I'll ruminate on them for a bit.  My thoughts right now lead me to fix the UI so that I don't have to "jury-rig" a table view.

Thanks,

Jean

_______________________________________________

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

  • Prev by Date: Re: Custom View in Toolbar
  • Next by Date: Re: Custom View in Toolbar
  • Previous by thread: Re: Displaying two different sub-entities in one table view
  • Next by thread: [SOLVED] Re: PopupButtonCell in a TableView column
  • Index(es):
    • Date
    • Thread