Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
- Subject: Re: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
- From: WhiteContainer <email@hidden>
- Date: Mon, 20 Mar 2006 23:47:28 +0100
Ok ok...many "No" in your answer...;-)
The lesson I learnt : a main rule when searching solutions, is to
exclude immediately all the ideas which does not respect the MVC
paradigm and more generally the guidelines of the apple doc. Be
creative but stay inside the playground...and respect the
terminology...:-D
This is a generic method to add an object to a relationship --
there is nothing specific to a table view here.
Ok, I understand now that the selection in the tableView is managed
via the bindings of the Add: button, and that this method has nothing
to do with the view.
Personally in this situation I would pass in a reference to the MOC
Marcus S. Zarra
I do not see what you mean by "pass in a reference to the MOC",
maybe MOC should be read MOM ?
No, he means MOC -- compare, for example, the NSEntityDescription
method insertNewObjectForEntityForName:inManagedObjectContext:.
Concerning this, I will be concrete : in my class method I have to
create an instance of a mo, so I use NSEntityDescription(...) and I
have to give it a moc. The only path I can see to reach the main moc
is [[[NSDocumentController sharedDocumentController]
currentDocument] managedObjectContext]]. The other alternative is to
create a new moc inside the class method.
In my particular case I have a third alternative which is to retrieve
the main moc from the arguments passed through my method, but this
third solution does not apply to other situations.
On 20 mars 06, at 18:02, mmalcolm crawford wrote:
On Mar 20, 2006, at 2:33 AM, WhiteContainer wrote:
So...I think my questions were really fundamental...:-)
Unfortunately the first sentence here suggests you don't yet
fully understand MVC.
mmalc
Let's see...and let's resume now and maybe add some ideas :
> NSPersistentDocument is the File's Owner, his boss is
NSDocumentController.
He is a kind of "super controller" because :
Why introduce new terminology? They're both controllers.
> NSManagedObjetContext is also a controller but maybe a new type
of controller, which plays in a kind of "MDC" paradigm : Model-
DeepDatas-Controller. He manages relationships between deep datas
(persistentStore) and their corresponding objects manipulated in
the code.
The context is a model-controller.
> When is it useful to create another MOC ?
- In another thread
- When using another NSPersistentStore
No. As the documentation states, a role of the persistent store
coordinator is to present a facade to the context(s) of one or more
persistent stores aggregated into one store. As my earlier
response stated, "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."
- I would add : maybe in a class method ?
No. In a class method you're more likely to pass in the context to
use...
So maybe in any place where [self managedObjectContext] returns
nil or will not give an access to all datas (many stores, custom
stores...) ? Is it better to create a new one than retrieving the
main moc with this path : [[[NSDocumentController
sharedDocumentController] currentDocument] managedObjectContext]] ?
No.
Personally in this situation I would pass in a reference to the MOC
Marcus S. Zarra
I do not see what you mean by "pass in a reference to the MOC",
maybe MOC should be read MOM ?
No, he means MOC -- compare, for example, the NSEntityDescription
method insertNewObjectForEntityForName:inManagedObjectContext:.
> Controller selection in MO :
There should be no reason for the Department object to access the
controller's selection.
mmalc
I agree but look at the following source code in the iClass
example from Xcode (Student.m).
It is an add: method based on the user's selection in a tableView
(to add some objects in a to-many relationship).
So a Department.m could have methods to set, get, calculate,
manage his underlying datas but also its own particular methods to
add: remove: insert: its datas...And to add objects in a
relationship, one of the most user-friendly way, is an add: based
on the user's selection in a table.
#import "Student.h"
#import "Course.h"
@implementation Student
(...)
- (void)addCourse:(NSArray *)aCourse {
Course *realCourse = [aCourse objectAtIndex: 0];
[[self mutableSetValueForKey: @"courses"] addObject: realCourse];
}
(...)
@end
This is a generic method to add an object to a relationship --
there is nothing specific to a table view here.
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