Re: core data - beyond the simple example
Re: core data - beyond the simple example
- Subject: Re: core data - beyond the simple example
- From: "I. Savant" <email@hidden>
- Date: Fri, 4 Apr 2008 11:04:03 -0400
> I have got a little demo project. I have a NSTableView bound to a Core Data
> array of objects that where I can edit the name. So that was the first easy
> step. Here are a few more:
A few points.
First, you probably want (or meant) to bind a column in your table
view to some keypath. This is 100% bindings-related. It's very
important for you to not only understand the difference or (because
you may already understand it) at least be specific about what is
bound to what.
Second, there is no such thing as a "Core Data array of objects".
Again, you need to be specific if you expect help. Core Data returns
collections as sets (NSSet or NSMutableSet).
Third, your table or column is bound to (most likely) an array
controller. The array controller's content set is bound, in turn, to
something else or it is set to Entity mode and will therefore contain
all instances of the specified entity (unless filtered with a
predicate -- see below). Again, be specific.
> 1.) What I want to do next is show all attributes of the object in my
> NSTableView. Right now I assume I need to subclass the NSTableCell and
> somehow make the NSTableView use that class instead. Then I will need to
> bind the individual attributes to the controls in that view. Is that the
> correct way to do it?
I'm not even sure how to answer this. You talk about cells then
switch to views. The usual scenario is to bind each *column* (not the
whole table) to a specific keypath (usually an attribute) of the
arranged objects of a controller. Since you're struggling with the
newness, I recommend doing it the usual way first, then getting
fancier later.
Since you haven't described the entity and its properties you're
representing in your table view, it's difficult to say exactly what
you'll need to do. Start there. For general things (strings, numbers,
etc.) no subclassing is necessary. To represent a color, you'll
probably need a custom cell as (I believe) there is no NSColorWellCell
or equivalent.
It's important to note that most of your problem (as you suspected)
is in fact due to lack of complete understanding of the Cocoa Bindings
mechanism(s). You *must* learn this if you are to 'master' Core Data.
A lot of your questions will "go away" if you master Cocoa Bindings
first.
> 2.) Instead of binding ALL the objects to the NSTableView I would like to
> filter the objects so only objects e.g. with attributes "color='red'" get
> shown.
>
> 3.) Now I would like be able to make this filter more dynamic. For example
> adding 3 buttons. "show red", "show green", "show all".
Look up "NSArrayController" and "filter predicate". Also look up
"NSPredicate" and the use thereof. This is all possible with these
mechanisms.
> 4.) Next thing would be to have this filter somehow defined dynamically.
> Having the user assigning the condition "color='red'" to the "show red"
> button and so on.
The answer to this depends on exactly how you want this to work. Is
the number of available buttons dynamic and dependent on some other
factor? Is this function purely user-definable?
Most likely, you'll want to assign a set of filter rules for the
button. If you're targeting Leopard or above, the Predicate Editor
control found in IB should help provide UI for the user to define the
filters for your controller.
> I was also wondering ...what if we are talking about 1M objects (or rows
> thinking of it in terms of a database). How does this scale?
See the many threads on this list (and the topic in the
documentation) regarding "Core Data performance". It's been documented
and discussed to death here in the past and recently.
> Also I am wondering about migrations. When you change the data model and
> users upgrade the application. How can one define the migrations?
Read the documentation. This is covered thoroughly. If you have more
specific questions, ask away.
--
I.S.
_______________________________________________
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