Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
- Subject: Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
- From: Quincey Morris <email@hidden>
- Date: Sat, 25 Oct 2008 13:01:39 -0700
On Oct 25, 2008, at 12:20, Jerry Krinock wrote:
I also have a more fundamental question. Why must we override -
initWithError:type: to initialize the 'department' ivar for new
documents? It seems like we're "faking it". Generally, best
practice is to allocate objects on-demand. And since good Cocoa
citizens should be using getters, I propose instead alloc-init-
setting it at the end of the getter -document implementation, after
accessing the ivar and fetching it from the store have failed.
But when I tried that, a newly-created document didn't "work" (user
could not type anything into any fields). NSLogging tells me that
my getter -document is not invoked during initialization and
therefore the -department ivar does not get set.
Apparently, sometime after initializing a new document, Core Data's
internal magic is directly accessing my 'document' ivar under the
table (and finding nil), instead of using the getter. How can I
change my thinking to understand that this is expected behavior I
need to design for?
Well, it's not clear what class your -document getter belongs to, or
why you're expecting it to be referenced by code you didn't write.
Core Data knows nothing about documents. NSPersistentDocument "merely"
wraps document behavior around Core Data.
For a new document, the Core Data object graph is empty, and there's
no automatic hook in either Core Data to add objects to the initial
object graph (i.e. the department object in your case). Normally, it's
either done in initWithType: or by using "prepares content
automatically" in an object/array/etc controller in the nib file.
If you were sure that your -document getter (wherever it is) was going
to get called early enough (before the user interface is displayed),
then lazily creating the department there would be fine.
_______________________________________________
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