Re: The Problems with NSController
Re: The Problems with NSController
- Subject: Re: The Problems with NSController
- From: Jonathan Hendry <email@hidden>
- Date: Mon, 27 Oct 2003 01:22:07 -0500
On Oct 27, 2003, at 12:44 AM, Hsu wrote:
1. It eschews the delegation design pattern. This makes it
difficult to extend and inconsistent with the rest of Cocoa.
2. It uses a lot of private APIs. NSAssociation has been replaced
by NSBinder and NSBinderAdaptor. NSAssociation, however, was public
and easily subclassed. NSBinder and NSBinderAdaptor are private and
undocumented. Altering the default behavior of the bindings is
impossible.
This is true, but it may be because of time-to-market concerns, or
concerns about overwhelming (new) users with more possibilitiies than
many of them need? EOF had a pretty good idea where they were going
and what their target audience was. It could be that Apple put out the
basic structure, and are looking to see where the developers want it
to go before adding the code. Once new API or behavior is added to the
'Kits, it's mighty hard to remove, so I can see Apple being very
careful about it. Backward compatibility is much more important to
Apple than it was to NeXT (for obvious reasons, I think).
I don't think that's true about NeXT. After all, EOF and Foundation were
initially released as an optional add-on to NeXTSTEP 3.2. They didn't
add them during
an epochal compatibility break like 10.3. EOF and Foundation added
functionality
without requiring wholesale replacement of the AppKit, or breaking 3.x
programs.
It's true that it's hard to remove API. Which makes me wonder even more
why the
NSController is the way it is.
3. It has no support for undo. EOF automatically registered all
edits, inserts, and deletes with the undo manager.
Of course, the objects that EOF managed were controlled by the
EOModel, which provided a great deal of meta-information about the
objects (such as which attributes are important, etc). I think perhaps
requiring an EOModel for a basic controller object is a bit more
complex than strictly necessary.
Are you thinking of database undo/rollback? I can't see how the Model
has anything to do with
Appkit-level Undo. Appkit-level undo applies to all attributes, even
ones that are
not important in the database schema. The Model would influence
rollback behavior
and referential integrity, which aren't really at issue here.
5. It relies on unsavory hacks to the runtime system. For a
controller to know about changes to a model object, your accessor
methods need to notify it of the change. In EOF, the developer added
a call to [self willChange] to each set method in his model objects.
NSController (which doesn't trust you to do this) replaces your class
with a secret subclass that does the "right" thing.
I'd expect AppKit/Foundation/CoreFoundation to be rife with unsavory
hacks to the runtime system. That's the point of AppKit/Foundation
now, really - do all the groddy stuff so we don't have to :)
In any case, I kind of like the Bindings way better - no more doing
the work by hand (or doing it through EOModeler, which is again
overkill for many many use cases). And it's overrideable if you so
desire.
EOModeler was nice because it generated code. ;^) And you could drag
things into IB,
so IB would know about attributes 'n stuff, automagically.
We need NSModeler, I think. Forget about the SQL stuff, just a nice GUI
tool
for creating skeleton model classes, which would generate source and be
integrated with IB.
(Note that this is not a list of bugs -- those will disappear in time
-- but only basic design errors.)
I don't really agree. I think the Bindings were a very focused
addition to Cocoa. I understand your frustration that it is so _very_
focused (given its EOF heritage) but at the same time, I think it's
more useful to judge it by what it brings rather than what it _could_
have brought if Apple had imported the EOF stack wholesale.
They're definitely an improvement, and it sucks to complain about
something people have been asking for, but I have to wonder about why
they seemingly threw out so much. It's
almost like they hadn't used EOF. (I haven't used Java EOF yet. Is
NSController like
that at all?)
If good demos is the goal, NSController is sufficient, but if Apple
is serious about the enterprise, they should take a long, hard look
at this poorly thought-out mechanism and yank NSController. They
could replace it with something more like EOF. Heck, they could just
recompile the old Objective-C EOF source code.
The Bindings seem aimed squarely at the desktop market. Looking at
them with Enterprise colored glasses on, I can certainly say they are
poorly designed, but I have a hard time saying that when looking at
them with Desktop-app colored glasses on. From that point of view,
they seem quite useful (not the garden of eden for sure - something
_like_ EOF would be a godsend), but certainly not the train wreck you
paint them to be.
I'm not entirely sure what "Enterprise" has to do with it, since the
database functionality isn't really at issue. Everything in EOF at the
UI level would be quite at home
in 'desktop' applications. And you never know when a customer is going
to try
to use your 'desktop' framework to do 'enterprise' work.
Seems to me that the NSController layer is to EOF's UI layer as DBKit
was to EOF.
_______________________________________________
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.