On Sep 5, 2012, at 5:39 AM, Jerry Krinock <je...@ieee.org> wrote: > (2) Separate, standalone object. Fancy housekeeping is needed to avoid > retain cycles, and crashes in corner cases as the document window is closing.
This is the way to go. That housekeeping doesn’t need to be so fancy; you just need to establish who owns what, and tear everything down in a deterministic fashion. This kind of standalone object is pretty much exactly what NSArrayController is; before bindings[1], developers created analogous reusable classes themselves, using things like NSTableColumn’s “identifier” property to store a model key path to use. If you have the option, I’d recommend just using NSArrayController for this. It does a lot of what you’ll need already, and you can still also implement a table view delegate and data source (possibly in your own subclass of NSArrayController) for additional behavior that you may need. I’d also recommend breaking out ownership of your document’s view side into its own NSWindowController sooner rather than later. While NSDocument will create a generic window controller for you automatically, it provides a good separation of concerns to have a custom NSWindowController subclass own the rest of your view, and to have the document concern itself solely with “document-like” things such as persistence. -- Chris [1] Those who used the Enterprise Objects Framework used a combination of EODisplayGroup and EOAssociation for this. EODisplayGroup was much more like NSFetchedResultsController in Cocoa Touch than NSArrayController in Cocoa, however. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
