• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CoreData : fundamental (or not) questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData : fundamental (or not) questions


  • Subject: Re: CoreData : fundamental (or not) questions
  • From: mmalcolm crawford <email@hidden>
  • Date: Sun, 19 Mar 2006 12:10:38 -0800


On Mar 19, 2006, at 11:35 AM, Joshua Scott Emmons wrote:
On Mar 19, 2006, at 11: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 ?
I suppose you could... I think this might be another design thing, though.

It is a perfectly good strategy to use additional contexts as you need to managed disjoint edits (see earlier post).


As I normally think of it, your average Document-based app works something like this:
+-------+
|window | \ ---------------- KVO ------------------
+-------+ \ / \
+-------+ \ +------------+ +------------+ +-----+
| panel | ---- | controller | <--MOC-- | NSDocument | <--MOC-- |Store|
+-------+ / +------------+ +------------+ +-----+
+-------+ /
| sheet | /
+-------+
So: NSDocument represents the Model


No, it doesn't.  The document object here is a controller.


(which is actually implemented with CoreData) via its managedObjectContext.

The context is another controller object.


The Controller is passed this MOC. It uses the MOC to send messages to to the Model. The controller is also responsible for maintaining all the views (windows, views, panels, whatever).

This is typically the responsibility of the document instance, although it may be distributed amongst other controller objects (notably if using Cocoa bindings instances of subclasses of NSController).


The Controller is also KVO-ing the Store. As soon as the store actually creates the MO, the Controller is sent a message. It updates the panel or window or whatever when it processes this message.

The controller should not be observing the store. It may observe the context using either KVO or the notification center, and update accordingly.

And for the sake of greatly simplifying things, there's no reason that reference should not be the same one returned by [NSDocument managedObjectContext].

On the contrary, *some* situations (as stated before, notably when you need to maintain disjoint sets of edits) are greatly simplified by having more than one context.

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


  • Follow-Ups:
    • MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
      • From: Joshua Scott Emmons <email@hidden>
References: 
 >CoreData : fundamental (or not) questions (From: WhiteContainer <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: Joshua Scott Emmons <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: WhiteContainer <email@hidden>)
 >Re: CoreData : fundamental (or not) questions (From: Joshua Scott Emmons <email@hidden>)

  • Prev by Date: Re: menuNeedsUpdate delegate
  • Next by Date: [SOLVED] NSDictionary writeToFile without going to disk?
  • Previous by thread: Re: CoreData : fundamental (or not) questions
  • Next by thread: MVC, DBA, CoreData (was: CoreData : fundamental (or not) questions)
  • Index(es):
    • Date
    • Thread