Re: A CoreData Limitation?
Re: A CoreData Limitation?
- Subject: Re: A CoreData Limitation?
- From: Nicko van Someren <email@hidden>
- Date: Tue, 17 May 2005 23:17:41 +0100
On 17 May 2005, at 22:55, mmalcolm crawford wrote:
On May 17, 2005, at 2:49 PM, Nicko van Someren wrote:
On 17 May 2005, at 22:13, mmalcolm crawford wrote:
...
If you want to follow this pattern (and I'm still not
sufficiently clear on the actual task to advise on that) then the
appropriate mechanism here would be to use a fetched property:
<http://developer.apple.com/documentation/Cocoa/Reference/
CoreData_ObjC/Classes/NSFetchedPropertyDesc.html>
Yes, I thought about that. The problem is that the orginal
request seemed to imply that columns needed to be dynamically
created and deleted whereas fetched properties are attributes of
the model entities and these can not be modified once there are
any instances of the entities. Thus it does not look to me like
you can create a fetched properties for a new column when it gets
created.
If this is the case, then it's not clear that Core Data is an
appropriate solution -- by overriding valueForKey: in the way you
propose you're basically subverting the idea of having a model.
Bill's follow-up addresses the issue in more depth...
I'm not sure I agree. The sparse table with row and column headers
model which I proposed seems to model what I think was the original
request. The nasty hack with valueForKey: is not there to subvert
the model so much as map it into a representation that will display
easily in an NSTableView using bindings and little extra code. As I
mentioned in my original reply, I think that the problem here is that
a table view does not match the underlying data he seems to be trying
to represent and some other means of representation may well be more
appropriate.
Nicko
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden