Re: The Problems with NSController
Re: The Problems with NSController
- Subject: Re: The Problems with NSController
- From: Hsu <email@hidden>
- Date: Sun, 26 Oct 2003 21:44:26 -0800
NSAssociation and careful use of delegation made EOF easy to extend.
It seems likely that, particularly for this release, the Bindings
weren't designed for "easy extension". Delegation (the AppKit way, with
informal protocols) can always be added later without too much trouble.
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).
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.
In the default Bindings case, where the changes are "magic" it might
get messy. I assume that if you do things manually
(automaticallyNotifiesObserversForKey && willChangeValueForKey) you can
also hook up to the undo manager at the same time.
4. It has no support for relational databases. EOF could bundle
all those edits into tidy SQL statements and put them into a
relational database for you. This was made possible by a carefully
defined data source protocol. You could easily create your own data
sources and slip them under the controller.
This seems to be unrelated to the design or implementation of the
controller - it's just a need for object persistance. The Bindings are,
conceptually, virtually unrelated to persistance. I think quite a few
developers can use the Bindings just as they are now. I don't argue
that the whole EOF stack would be great, but again, that requires
EOModeler, an adaptor, some sort of database (embedded, system-wide, or
provided by the developer), etc. I'm not convinced that Apple wants to
just release all that to the public and suddenly be committed to make
it work forever.
There is also a bright side to this separation - it means that you
don't have to have persistance to make this all work. One of EOF's
shortcomings in my experience was trying to get EOF to do object
management without persistance - since it often assumed that there was
a database somewhere down there, there was much pain involved if there
wasn't. I'd like the idea of Apple bringing back all the technology
that made up EOF, but independant in a way that you only had to work
with the bits that you were actually going to use.
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.
6. It was created in a vacuum and rushed to market. No one at
Apple has ever created a realistic application with NSController.
The design, the implementation, and the documentation would all be
better if someone at Apple had been required to actually use
NSController.
The documentation always lags - it's just a way of life, I think :)
(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.
I have met a few people who claimed that EOF was hard to use. These
people, regardless of what was written their business cards, were not
programmers. I'm glad that they decided to work in PowerBuilder or
Visual Basic -- I'm certain that regardless of the tool they chose,
these people never produced an application of any worth.
I'd have to hope that you were joking here. People write real programs
in PowerBuilder or Visual Basic. They make money off of them, and they
do what they are supposed to. EOF solves a specific set of problems,
and it does it quite well, but it also has quite a steep learning
curve, and quite a lot of quirky behaviors to figure out. What I want
from Apple is something as easy to use as PowerBuilder or Visual Basic,
but as powerful as Cocoa is now. (I think the
DirectToWeb/DirectToJavaClient technology from Apple's WebObjects as a
good example of something that is simple to use, but still quite
powerful).
EOF and Cocoa were designed to give real power to real programmers.
NSController and the bindings mechanism were designed to give power to
people doing demos.
Again, it seems almost insulting. I have an app where the app
functionality tool about an hour to write (mostly looking up
documentation and deciding how the UI would look). The preferences
panel and associated code took 3 hours to write - time which could have
been cut probably by 2/3s by using the Bindings, which enhanced
functionality as a bonus.
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.
Karl
--
That which does not kill me had better run pretty damn fast.
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
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.