Re: CD: Creating a managed object
Re: CD: Creating a managed object
- Subject: Re: CD: Creating a managed object
- From: "Marcus S. Zarra" <email@hidden>
- Date: Tue, 29 May 2007 18:26:52 -0600
The view's delegate is not part of the view in MVC. Your delegate to
the view is normally a (window) controller not another view object.
As for subclassing NSArrayController, that is unnecessary. If you
configure the NSArrayController to contain instances of your
NSManagedObject (as opposed to NSDictionary objects) then you can
call insert: on it and it will create a new object for you. However,
if you are doing that in the view then that is breaking the model also.
As a few people have suggested, you could have the view call a method
on its delegate (a controller) passing in the information and let the
delegate handle object creation. This fits the MVC pattern.
Marcus S. Zarra
Zarra Studios LLC
www.zarrastudios.com
Simply Elegant Software for OS X
On May 29, 2007, at 6:17 PM, Ian Joyner wrote:
On 29/05/2007, at 9:18 PM, I. Savant wrote:
On May 28, 2007, at 11:42 PM, Ian Joyner wrote:
OK, even if this is not quite right, it's only a small routine to
refactor, so I think this is pretty clean (the only thing I'm
uneasy about is manipulating a model object in a view, but
perhaps that is alright.
I think you need to go back to the fundamentals in the
documentation and put in some serious review/research time before
continuing any further.
Um, that's exactly what I am doing! Unfortunately, all of Apple's
tutorials and Core Data documentation and examples (that I've seen)
deal with simple cases where you connect an 'add' button to an
NSArrayController through IB's binding interface. Works nicely
without any code, but how to handle CD entities being created in
other means in response to other user actions is the question.
(That bit already works manually, but I want to automate it and
remove the add button (and record coordinates).)
There's simply no good reason for your approach.
It works, that's a good reason so most people would go no further
(OK, I've been around for long enough to see a little further down
the track). Some people would argue that MVC is a heavy-weight
pattern and it's cracking a peanut with a sledgehammer.
You should consider data source and delegate style methods (like
NSTableView). Study NSTableView's design and do it that way.
Something like -myView:didClickAtPoint: ... if that's sent to a
delegate (your controller) the delegate can respond by creating a
new model object and any housekeeping.
But a delegate is still part of the V in MVC – it's really just an
extension of the view class without subclassing. It makes sense for
NSTableView to do this, since it needs to be left open for others
to use it. In my case, I have a simple custom view, which is only a
part of this application, so will not need extension or clever
features in the future. There's not much distinction between
mouseDown and didClickAtPoint – you still need to intercept it
somewhere.
What occurs to me is to subclass NSArrayController, and change the
add method to handle the model object:
MyArrayController.....
-(void) add: (NSEvent *)event { // OK, I don't think covariance is
allowed (or even needed) in Obj-C
NSPoint p = [event locationInWindow];
NSManagedObject *mo = [nsa newObject];
[mo setValue: [NSNumber numberWithFloat: p.x] forKey: @"x"];
[mo setValue: [NSNumber numberWithFloat: p.y] forKey: @"y"];
}
In the view:
IBOutlet MyArrayController *nsa; // Connected in IB
...
-(void) mouseDown: (NSEvent *)event {
[nsa add: event];
}
I think this follows the MVC pattern Figure 6.3 on p123 of
Hillegas, just the NSButtons have been replaced by my view. Of
course if there is another way to make this work without
subclassing NSArrayController, then I'm happy to hear. If this is
the Cocoa intended way of handling this situation, I'm happy to
hear that too.
Any time you have a view directly interacting with a model or
vice-versa, your design is incorrect.
That's exactly my original point. However, it has to be said that
there are lots of working programs with incorrect designs. I prefer
the former, but being a purist (so I think we're on the same side),
I want a clean design as well. Someone even said, if you are
writing code in Cocoa you are probably doing it wrong. I tend to
get the feeling that's good advice.
Sorry, I know you were probably trying to be helpful, but there is
a little bit too much of "go away and read the documents" (pointers
are fine) whenever someone asks a question in these Cocoa groups,
and you might find someone already has read all the documents and
scanned the example code. It's not the same as a university tutor
telling a student to find it out for themselves (I've been there
and done that too). I think the use of Core Data and Bindings is
still so new (many people are still doing things the old way), that
a lot of required patterns are not widely known yet. I'm just
exploring well what really is the best way of doing things. I think
people are more tolerant of idiot questions in the WebObjects
groups (reason for question might not be so idiotic after all).
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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