Re: CoreData : fundamental (or not) questions
Re: CoreData : fundamental (or not) questions
- Subject: Re: CoreData : fundamental (or not) questions
- From: mmalcolm crawford <email@hidden>
- Date: Sun, 19 Mar 2006 11:57:30 -0800
On Mar 19, 2006, at 9:48 AM, Marcus S. Zarra wrote:
On Mar 19, 2006, at 10:39 AM, WhiteContainer wrote:
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 ?
Others may correct me but one MOC per NSPersistentStore per thread
is a good rule. I would not use a different MOC for another window
just another thread.
Both of these are valid reasons for using additional contexts (for a
work-in-progress example of the former [using a separate context for
a sheet] see <homepage.mac.com/mmalc/CocoaExamples/
DepartmentAndEmployees2.zip>).
A context simply acts as a scratchpad. You obviously need one in
order to be able to work with Core Data model objects. You can use
an additional context or contexts whenever you need to managed a set
of edits that is disjoint from those in whatever other context you
are using.
On Mar 19, 2006, at 9:39 AM, WhiteContainer wrote:
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
Unfortunately the first sentence here suggests you don't yet fully
understand MVC. There should be no reason for the Department object
to access the controller's selection. The role of the controller is
to mediate between the model and the view.
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