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 10:46:38 +1000
On 30/05/2007, at 9:09 PM, I. Savant wrote:
On May 30, 2007, at 1:50 AM, Ian Joyner wrote:
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).
NSView is *meant* to be subclassed. It's all but useless to
developers otherwise. You can add anything to it you want / need to
get things done. It's not artificial, it's what you're meant to do.
Whether it's packaged into a framework or not is entirely
irrelevant, if you want a custom view, you subclass NSView.
Additionally, "a delegate" can be whatever you want it to be. So
can the delegate methods you add. It's a messaging mechanism that
allows others to help decide how the delegator is to do things.
That's all.
OK, my last post simplified the fact that I am subclassing NSView
(and as was shown in my original posts). I'm not going to use
delegation just because I can, but only if it's appropriate (better
to be tasteful in design like Apple, not Microsoft).
Regarding MVC design, it's fairly flexible and there's no one
right way to design your app according to this pattern, but
outright breaking it in a Cocoa app is quite simply a bad idea. Not
because all applications that don't adopt the design pattern are
inherently flawed, but because *Cocoa* applications use an API
designed this way.
I was not arguing against MVC, rather for it. (I know there are some
irritating people who just go round poking holes in things, but that
was not the purpose of my question.) The simple question was what is
the best way to handle this using Cocoa Bindings and Core Data, given
that the simple situation I have outlined has no sample code, is not
explained in Apple docs or tuts, and Bindings are generally too new
to be in most books. Core data is certainly not covered in any Cocoa
books yet. Here is a survey:
Bindings
Core data
Anguish et al (2003) no no
Learning Cocoa (2001) no no (I
suspect not in Learning Cocoa with Objective-C either)
Hillegas (2004) yes no
Hillegas and Dalrymple no no
Zobkiw (2003) no no
Kochan (2003) no no
(wouldn't expect it in a new version either)
Singh (2006) no
no (wouldn't expect it in here)
As you can see not a lot in there. Core Data Programming Guide shows
how to create entities, but not where to put the code. All the sample
code (both Apple's and others I've seen) show how to add tables and
'add' buttons. It's all very IT, but I think CD is more than that.
MVC is about putting objects into clusters and reducing surface area
between those clusters to avoid complexity and thus programming error
and making things easy to extend in the future (rather like an
argument I had about gotos with someone recently). That's exactly
what my question was about – finding an architecture for something
that hasn't been covered elsewhere.
You may have been offended by my telling you to go back and read
some more, but you're going to have to get over it.
Well, see the above. Your diagnosis is wrong.
The plain fact is, you're trying to run before you walk and you're
missing some big, important points along the way and it shows.
I've been doing Mac programming since 1984, MacApp since version 0.3
(until they wrecked it by converting it to C++), OS X since 2000, and
WebObjects for several years. And in another life loads of system-
level programming in ALGOL. I've done enough to know there's always
more to know. Your diagnosis is wrong again.
You're being argumentative with everyone who's given you answers,
No, I've taken issue with the sentiment of "go away you don't know
enough to play with us big boys yet". If you do this to someone who
has a lot of Mac and other experience, how will genuine newbies
feel.... they'll just go and do windows where it's easier (to get a
job and pays better). So don't be patronizing in your responses to
people, it's not good netiquette, whatever level they are at.
which suggests you're only interested in making people tell you how
to make it work *your* way.
I didn't have a way, some ideas, so I posted here to find out how
other people would handle the situation, not to be lectured on going
and doing more reading – I've read it all. I'm interested in what the
alternatives are and the tradeoffs and the decisions to make in
adopting an approach. Your diagnosis is wrong again.
Good luck with that.
I think this could have been an interesting and constructive
discussion. There is always a case for questions like here's how I'm
thinking do others have better suggestions.
_______________________________________________
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