Re: Core Data / Bindings question
Re: Core Data / Bindings question
- Subject: Re: Core Data / Bindings question
- From: Phil <email@hidden>
- Date: Tue, 26 Jun 2007 18:48:07 -0400
On Jun 26, 2007, at 5:55 PM, Chris Hanson wrote:
On Jun 26, 2007, at 1:54 PM, Phil wrote:
I'm trying to create a binding to an entity so that I can observe
any additions to the entity in question but am not clear on how to
accomplish this.
What do you mean by "create a binding to an entity"? When working
with Core Data, it's critical to use the terminology correctly.
Apologies... I'm aware that I'm still struggling with terminology
(and probably my mental model of Core Data... having a RDBMS
background definitely seems to be more of a hinderance than a help as
I've had more trouble wrapping my head around this framework than any
other so far) which is likely the reason I'm having trouble with this...
Do you want to use an array controller bound to all instances of an
entity? Or do you want to see property changes in your interface
for a particular instance of an entity?
I've got a) an array controller bound to all instances of an entity
(which works as expected) *and* I need to b) see property changes in
my interface for a particular (i.e. all) instance of an entity. But,
if I'm understanding this correctly, before I can do b) I need to
create a binding on the property of interest in the new instance(s)
as they are created. Therein lies my problem: in looking at example
apps like Sketch, this is not done via the array controller (which
doesn't appear to have the means to do this), but rather the
collection object directly (in the case of Sketch, binding to
'graphics' which is simply the accessor for the NSMutableArray.) So,
I'm thinking that I'm just moving the collection into an entity using
Core Data but don't understand how to create the equivalent binding
so that I can observe as instances are added for an Entity to create
the property bindings. Does this make sense or am I completely off-
base?
Also, binding in code ("manually") won't be very different than
binding in Interface Builder, and it won't be very different for
Core Data versus non-Core Data. You'll just be sending -
bind:toObject:withKeyPath:options: to the view or controller that
you want bound, passing the controller or model object
(respectively) that you want your view or controller bound to.
The main difference between bindings when using Core Data and when
not using it is that when using Core Data, your controllers should
generally be in entity mode with an entity specified, and should
have their managed object context either bound or set appropriately.
If you want to see some examples, just option-drag an entity
definition out of the Xcode modeling tools into a new empty window
in Interface Builder, and inspect the various bindings that are
created there. The automatic interface generation mechanism isn't
doing anything you can't do yourself in Interface Builder, and
Interface Builder in turn isn't doing anything you can't do in code.
True enough... just a personal preference to see it done in code
first if possible as I've found it's all too easy for me to not
notice something important in IB while I'm still working to
understand what's going on under the covers.
_______________________________________________
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