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: Wed, 30 May 2007 15:50:49 +1000
On 30/05/2007, at 10:26 AM, Marcus S. Zarra wrote:
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.
By "view object", do you mean object derived from NSView? To be a
part of the V, an object does not have to be an explicit view object,
just a general supporter object working within the V of MVC. And
NSWindowController is a controller not in the NSController hierarchy
(but I think this is historical more than anything).
As for subclassing NSArrayController, that is unnecessary.
Right, by my reasoning above, I don't have to inherit NSController
for a class to be in the Controller group, so I could have my own
controller with the NSArrayController as a reference to do as I had
in the view class. I had not thought that subclassing anything in the
NSController hierarchy was a recommended suggestion (in any of
Apple's docs that I've seen). However, that intermediate controller
object only removes a little bit of code from the view class and
since the view class references and uses it, it's heavily related to
the V anyway. But the purpose of the C layer is to remove all that
messy code from the V and M layers. So it's probably a better
approach in the long run as the app gets bigger and more messy (I
hope not).
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.
I got your suggestion from your last post – still looking into it.
NSView doesn't have a delegate, and it seems a bit artificial to
build the delegate mechanism into an app class (a reusable framework
class would be entirely different). Then again the "Learning Cocoa"
book says MVC is not a hard and fast thing (is there going to be a
new version of this book after that which is under NDA is released?).
I suspect we are (maybe particularly me) are trying to make MVC too
hard and fast.
Anyway, I have just found another example to look at, so will let you
know how I go. Thanks for your suggestions.
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