Re: CoreData : fundamental (or not) questions
Re: CoreData : fundamental (or not) questions
- Subject: Re: CoreData : fundamental (or not) questions
- From: WhiteContainer <email@hidden>
- Date: Sun, 19 Mar 2006 18:39:23 +0100
1- Ok, that confirms my opinion. Maybe in a sheet or in another
window (where user can edit and create mo) should we use another moc ?
2- Yes, I meant subclass of mo.
For sure, but if you want to access the moc in a + classMethod (of
i.e Department.m), [self managedObjectContext] does not work, because
"self" (the class) is not a mo.
That's why i used this path which works, but it seems to me it is not
so good to use it, maybe a source of conflicts when many docs are
opened :
+ myClassMethod {
....
...[[[NSDocumentController sharedDocumentController] currentDocument]
managedObjectContext]]...;
....
}
3- Ok for the MVC, but if you want to access to the selectedObject of
a controller inside the code of your Department.m ? Maybe all the
communications with controllers should be managed by MyDocument and
then results of these "questions to the controller" should be
retrieved from MyDocument by Department.m ? In that case, how can I
access a result of a method in MyDocument from Department.m ? Using
@import (I think it will work only for class method, won't it ?) ?
PS - As you can see my problem is mainly communications-based...:-)...
I understand standard MVC-outlets-actions, I understand
controllers&bindings, I understand CoreData structure, but it is
another story to find the good way to make all of these things
playing together, especially if you need to go a little bit out of
the main working !
On 19 mars 06, at 17:23, Joshua Scott Emmons wrote:
These are not cannonical answers -- just based on my usage of it.
1- In which cases is it necessary to create another
managedObjectContext, instead of using the default moc of the
NSPersistentDocument ? Of course if you have different persistent
stores it seems to be necessary, but in the simple case : 1
managedObjectModel, 1 persistentStore ?
I've never found a reason to if you only have one persistentStore.
And keep in mind that the Document-based Application model uses
NSDocument's managedObjectContext to abstract most of this away
from the programmer anyway. By which I mean: in a multi-document
application, you will have a persistent store for EACH document.
This means you will have a separate managed object context for each
document. But as long as you are always using the managed object
context of the document you are interested in (by calling
[NSDocument managedObjectContext], you never really have to think
about it.
2- How can I access the default moc of the document from an entity
(I mean by entity, a class created from an entity) ?
I'm a little unsure what you mean by "class created from an
entity", but I think you mean an NSManagedObject or subclass
thereof. If that's the case, you can call [NSManagedObject
managedObjectContext] to get the MOC of that entity (and anything
else in that entity's store). The only time that wouldn't work is
if you have multiple stores and are trying to get the MOC of a
store that your entity isn't a part of.
3- How can I access the methods of an arrayController from an entity?
Generally, I don't think this is a good design decision. It will
likely make things more confusing down the road. In the whole MVC
scheme of things, your managed objects, entities, relationships,
and all that CoreData jazz are your Model. Your NSArrayController
is (obviously) your controller.
Ideally you'd want your Controller to tell your Model things like
"Create a new thing" or "Delete this thing". You want your Model to
say things like "I have created this" and "I will delete this".
Calling methods of your Controller from your Model insinuates that
you are going to have your Model make the Controller say "Create
this" or "Delete this" which is kind of self-referential and messy.
If what you are looking for is a way to let your Model tell your
controller "I've created this" or "I've deleted this" (so that the
controller could update the view or something), it's already done
for you in Core Data! Just set your controller up to do some KVO of
your managed objects:
[myController addObserver:myManagedObject
forKeyPath:@"myPropertyOrRelationship" options:0 context:NULL];
Whenever myPropertyOrRelationship changed, myController is sent a
-observeValueForKeyPath:ofObject:change:context:
message. Note that depending on the values of options: and whether
this is a property or a relationship you are observing, ofObject:
and change: can pass in some really interesting values.
Doing things up this way prevents you from adding any application-
specific code to your model. Everything is in your controller
instead, keeping things nice and neat. If you don't know how to use
a method like this to solve your problem, maybe you could describe
it and see if someone here can find a way to make it fit? I really
think calling your controller from your model would be a bad idea.
Cheers,
-Joshua Emmons
_______________________________________________
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