NSController revisited
NSController revisited
- Subject: NSController revisited
- From: Aaron Hillegass <email@hidden>
- Date: Tue, 4 Nov 2003 09:25:12 -0500
A week ago, I posted some rather harsh criticisms of NSController.
I've spent the intervening week at the O'Reilly Mac OS X Conference.
Scott Anguish, Bill Bumgarner, and Mike Ferris (honest men and
redoubtable engineers all) took the opportunity to explain to me the
beauty of NSController. In each case, the thesis was the same:
"NSController is not perfect, but life with it is better than life
without it."
After many demonstrations of the power of NSController ("Aaron, this
app was 252,500 lines of code, but with NSController it is only 3!"),
I must agree with them: life is better. They also agreed with me:
there is much room for improvement.
So here are the points again, and I'm going to recant on a couple:
1) "NSController was rushed to market."
I think this is an industry-wide problem. Ever since the invention of
"Internet-time", management everywhere has been underestimating how
long good software takes. Good software (especially good frameworks)
involve careful design, implementation, testing, and documentation.
People argue that Apple can shoe-horn in automatic undo, extensibility,
persistence, and applescript support in the future -- these people
claim that it is better to have something now than wait forever for the
perfect controller. I understand this, but I like to think there is a
healthy medium between the extremes.
2) "It uses a lot of private APIs."
Bill Bumgarner (who did some work on NSController) assures me that this
will be fixed.
3) "It eschews the delegation design pattern."
In particular, I still believe that NSArrayController needs a delegate
outlet. Here are the minimal delegate methods it needs:
- (id)arrayController:(NSArrayController *)ac
willAddNewObject:(id)newObj;
This method would give you a chance to initialize a new object with
default values (or replace it) before it is displayed
- (NSIndexSet *)arrayController:(NSArrayController *)ac
shouldChangeToSelection:(NSIndexSet *)is
This method would give you a chance to control whether the selection
was allowed to change. It would also give you a chance to update the
parts of your UI that are not NSController-driven.
Given these two, you can imagine several more. When automatic undo is
added, you'll probably also want things like:
- (NSString *)undoActionNameForChange:(NSKeyValueChange)kvc
ofKey:(NSString *)aKey forObject:(id)anObj;
4) "It relies on unsavory hacks to the runtime system."
I was a big dummy on this one. It isn't bad, and you can turn this
behavior off.
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)key
{
return NO;
}
And call the notifications explicitly:
- (void)setFoo:(int)x
{
[self willChangeValueForKey:@"foo"];
foo = x;
[self didChangeValueForKey:@"foo"];
}
Mike Ferris points out that "unsavory hacks to" should really be
"clever use of". He is right. I was wrong.
5) "No support for relational databases."
Apple still hasn't come up with an elegant way to access relational
databases, and it is a source of great frustration for me and everyone
else who tries to sell services to the enterprise. We keep asking, and
no answers seem to come. So we ask louder. The result is ridiculous
diatribes like mine. I'm sorry that my frustration was misdirected at
NSController -- it is a good addition to Cocoa and will get even better
with time.
NSController was created by Andreas Wendker with whom I have never
worked, but every engineer that I spoke with expressed total respect
for Andreas and his skills. This, more than anything else, has
convinced me that Apple is not painting itself into a corner by
releasing NSController in its current condition. I'd like to apologize
publicly to Andreas: I should have given him the benefit of the doubt.
Sincerely,
Aaron Hillegass
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.