Re: Core Data & ManagedObjectContext
Re: Core Data & ManagedObjectContext
- Subject: Re: Core Data & ManagedObjectContext
- From: Mike McCabe <email@hidden>
- Date: Thu, 24 Jan 2008 08:55:30 -0500
Phil,
I think one method of doing what you want to accomplish is to create
IBOutlet variables and then tie the controllers and things using
Interface Builder...
As an example... I needed to be able to have a separate window that
would have access to a table in my managedObjectContext... So I
created an IBOutlet for an NSArrayController variable and then tied it
to the Array Controller using bindings in IB. This allowed me to have
access to the variable. You should be able to do the same thing
between your WindowController and the AppDelegate...
Mike
On Jan 24, 2008, at 3:24 AM, Philip Bridson wrote:
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
_______________________________________________
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