Re: CoreData relationships in IB
Re: CoreData relationships in IB
- Subject: Re: CoreData relationships in IB
- From: T Reaves <email@hidden>
- Date: Sun, 22 May 2005 19:41:20 -0400
On May 22, 2005, at 6:16 PM, mmalcolm crawford wrote:
On May 22, 2005, at 2:51 PM, T Reaves wrote:
If all you've done is bound a text field's 'value' to a property
of objectB, I'm not sure why you'd expect an instance of ObjectB
to be created automatically if none exists?
Just as you would if Core Data and bindings were not involved,
you still have to instantiate variables... A further issue
here, though, is ObjectA a subclass of NSManagedObject? If so,
you cannot simply create an instance with 'new' -- it must be
inserted into the managed object context etc...
What I'm wanting to do is very common; so common, I thought
that perhaps Apple would have added functionality to support it.
It's still not clear what you actually want to do...
You started off saying that "The fields for ObjectB are bound to
objectB.field". Do you want objectB to be created only if the user
types in a value, or should it be created automatically whether or
not the user tries to set a value?
Again, I apologize for not being clear.
I suppose that which of the two methods you describe would be
tenable, but my leaning would be to instantiate when a value was
entered, not automatically. Kind of like lazy initialization.
It would not have been too difficult to have added another
item in IB's inspector that said 'Create referenced/contained
object if nil' or some-such. Needing to manually create contained
objects is not bad, but it does increase the amount of work the
developer has to do.
Please file an enhancement request -- although my personal feeling
is that this sort of logic probably belongs at a layer below the UI.
Interesting. How can you apply that logic to a contained class,
and not the containing class? I mean, if the UI has logic to create
any class, it's sort of illogical to start using the slipper-slope
argument, no?
If a controller has an add method to instantiate a class, having
it instantiate it's attributes is reasonable. The issue is further
clarified by realizing that when I type in a value to
objectA.someField where I've defined that field to be a String, an
NSString (or subclass) is instantiated, correct?
So why is instantiating one class - an NSString - some how
better than instantiating another class - ObjectB? An object is an
object...
I do believe that I can create an instance in the managed
object context etc. simply by sending the 'new' message via
polymorphism.
No, you can't. You can use the convenience method in
NSEntityDescription, or you should use NSManagedObject's designated
initializer. If you're using an NSController then add: (and for an
array controller insert) will create a new managed object and
insert it into the bound managed object context etc.
O.K.
_______________________________________________
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