• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CD: Creating a managed object
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CD: Creating a managed object


  • Subject: Re: CD: Creating a managed object
  • From: Ian Joyner <email@hidden>
  • Date: Wed, 30 May 2007 10:17:33 +1000

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


  • Follow-Ups:
    • Re: CD: Creating a managed object
      • From: "Marcus S. Zarra" <email@hidden>
References: 
 >CD: Creating a managed object (From: Ian Joyner <email@hidden>)
 >Re: CD: Creating a managed object (From: mmalc Crawford <email@hidden>)
 >Re: CD: Creating a managed object (From: Ian Joyner <email@hidden>)
 >Re: CD: Creating a managed object (From: mmalc Crawford <email@hidden>)
 >Re: CD: Creating a managed object (From: Ian Joyner <email@hidden>)
 >Re: CD: Creating a managed object (From: "I. Savant" <email@hidden>)

  • Prev by Date: Re: Weird problem involving memory management and global variable
  • Next by Date: Re: Weird problem involving memory management and global variable
  • Previous by thread: Re: CD: Creating a managed object
  • Next by thread: Re: CD: Creating a managed object
  • Index(es):
    • Date
    • Thread