Re: CD: Creating a managed object
Re: CD: Creating a managed object
- Subject: Re: CD: Creating a managed object
- From: mmalc Crawford <email@hidden>
- Date: Wed, 30 May 2007 19:27:45 -0700
On May 30, 2007, at 6:25 PM, Ian Joyner wrote:
Reviewing this original question and after some thoughts from Mr
Crawford, I think it is more about bindings and the NSController
architecture (no surprise there), rather than Core Data.
With Cocoa bindings, you just connect up the bindings in IB and
messages just get passed to the right things and it works. The great
thing about Cocoa bindings is you don't have to write all that messy
code that you normally have to in the controller part (thanks to KVC/
O). However, what I needed to do was to record something that
happened in the view in the CD model entities (this isn't your
typical IT app). (It's actually a bit like a game, but user actions
are recorded, hence use of CD.)
Ultimately many views have to do "this sort of thing" -- as noted,
it's not really specific to Core Data, so the view has to interact
with "something" to get its job done. The NSController object is the
*intermediary* between the view and the model objects, so interacting
with that should not be considered sacrilege. Consider the
GraphicsBindings example at <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
>: both the GraphicsView and the Joystick interact directly with the
controller...
Consider also the createGraphicOfClass:withEvent: method in Sketch...
I didn't like putting manipulation of a CD entity in the view, but
using bindings, the controller bit seemed rather closed off. So the
question is how to get controller code into the bindings scheme of
things.
It occurred to me that maybe I could subclass NSArrayController, not
necessarily an appealing thought (hadn't seen it done anywhere
else), and Marcus Zarra didn't like it either (thank you).
I'm not sure what is the impediment to subclassing any of the
controllers? You're devolving to them responsibility for managing
model objects, and if that needs to be customised then the controller
object is a suitable locus. Several of my samples at <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
> use subclasses of NSArrayController (for example, the Bookmarks
example uses the array controller to support drag and drop). When
all's said and done, the NSController objects are still *controller*
objects. One way of thinking about them (part of the idea behind my
WWDC session <http://developer.apple.com/wwdc/tracks/macosx.html>) is
that they represent a re-factoring of common controller patterns so
that you can leverage reusable components instead of having to re-
write the glue code for every application. But this abstraction does
not mean that they become entirely closed black boxes...
mmalc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden