Re: Core Data & ManagedObjectContext
Re: Core Data & ManagedObjectContext
- Subject: Re: Core Data & ManagedObjectContext
- From: Philip Bridson <email@hidden>
- Date: Thu, 24 Jan 2008 00:24:40 -0800
Hi there, you'll have to excuse me but I haven't slept in 6 weeks and its driving me mad, but I may have a possible solution to my own problem.
If I created a custom initialize method for each window controller, with a managedObjectContext instance for each window, and passed in a pointer to the the original context wouldn't that work? That way, technically I wouldn't be creating 'multiple' context's.
Any ideas?
Many thanks,
Phil.
On Thursday, January 24, 2008, at 05:59AM, "Philip Bridson" <email@hidden> wrote:
>Hi there, thank you for your response.
>
>I have read the documentation on this but still I am afraid I am a little confused. To help clarify what I am trying to do I will explain using the Doc's tutorial on Employee/Department.
>
>In the tutorial you create a user interface and bind the Text Fields to the array, which is connected to the App-Delegates context. This enables me to edit information from the front end. But what if I wanted to add an 'Edit' button that would open a new window, stored in a separate nib and have the Fields in there bound?
>
>In the documentation it says I can have multiple contexts and multiple stores for each stack but only one persistent store locator. I have tried this, but it does not work as I cannot pass in the original store locator from the Apps delegate into my window controllers context. It would be easier if I could make the App delegates context globally available but I don't know how.
>
>The doc does show a way of editing the store programatically, maybe, due to the fact I want to do actions, this would be the way to go.
>
>Many thanks,
>
>Phil.
>
>On Thursday, January 24, 2008, at 01:24AM, "William Turner" <email@hidden> wrote:
>>Hi Phil,
>>
>>I'm not sure why you want a different context for each window. Each
>>context is a separate "scratchpad" for the underlying data store - do
>>you really *want* to perform edits in separate contexts? That often
>>results in additional complexity merging changes, etc., between the
>>contexts. If you just want to be able to access the store via more
>>than one nib, you should be able to make the application delegate's
>>context available to all of those nibs.
>>
>>For your second question - when a text field is bound you can have it
>>continuously update the model or only when editing ends. You can also
>>implement validation methods in the model object. If you want to
>>involve an action before the data is sent to the model, then bindings
>>may not be your solution - you may want to implement that part of your
>>app with target-action instead.
>>
>>I'm not completely clear on either of your problems/goals - if the
>>answers I gave aren't sufficient maybe you could describe what you
>>want to do in greater detail.
>>
>>Wil
>>
>>On Jan 23, 2008, at 12:43 PM, Philip Bridson wrote:
>>
>>> Hi there,
>>>
>>> If I create an managedObjectContext for each of my windows in an
>>> application, and pass in the persistent store co-ordinator for the
>>> application will this allow me to edit information in the store via
>>> separate nibs as at the moment it will only let me bind to the
>>> applications delegate. Also, if I bind an NSTextField to the
>>> NSArrayController, it automatically stores the information that is
>>> supplied, how can I pass the information to a method first,, say by
>>> clicking OK, BEFORE submitting the information to the
>>> NSArrayController?
>>>
>>> Many Thanks,
>>>
>>> Phil.
>>> _______________________________________________
>>>
>>> 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
>>
>>
>>
>_______________________________________________
>
>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
>
>
_______________________________________________
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