Re: CoreData relationships in IB
Re: CoreData relationships in IB
- Subject: Re: CoreData relationships in IB
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 22 May 2005 16:51:44 -0700
On May 22, 2005, at 4:41 PM, T Reaves wrote:
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?
I'm not sure what you mean.
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...
There's a difference between instantiating a single string that's an
attribute of an object and backfilling an object to contain a string
that you want to set as an attribute thereof.
mmalc
_______________________________________________
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