Re: CD: Creating a managed object
Re: CD: Creating a managed object
- Subject: Re: CD: Creating a managed object
- From: Ian Joyner <email@hidden>
- Date: Thu, 31 May 2007 13:29:06 +1000
On 31/05/2007, at 12:27 PM, mmalc Crawford wrote:
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...
Excellent, I'll study that graphics bindings example closely. Your
other examples look helpful too.
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).
Thanks for answering the question of subclassing NSControllers. That
sanctions doing a lot (without it being a hack).
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...
I think you've given me the step I need. Thing is Cocoa does such a
good job of providing most of the code for you, sometimes it's
difficult to work out where to slot your code in, so that it's not
something that goes completely against what was intended, which will
lead to problems later.
Thanks very much
Ian
_______________________________________________
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