Re: The problem with bindings
Re: The problem with bindings
- Subject: Re: The problem with bindings
- From: mmalcolm crawford <email@hidden>
- Date: Thu, 29 Jul 2004 22:42:19 -0700
On Jul 29, 2004, at 3:50 PM, Brent Gulanowski wrote:
I think KVO is by far the most obscure and difficult to adapt one's
thinking
to. This I think correlates with the fact that KVO does the most
behind-the-scenes manipulation.
Could you explain in greater detail your difficulty?
(This is written in the spirit of investigation, not deprecation.)
The basic aim of KVO is simple:
It provides a mechanism for change notification.
There are two parts to it:
(a) You have to tell an object you want to be told when one if its
properties changes.
(b) You have to implement a method that the observed object will use to
tell you of a change (*).
In many respects it's conceptually a specialised case of standard
NSNotifications, with which people typically don't seem to have much
difficulty. A main difference(**) is that, whereas with traditional
notifications you get to specify the method that gets called when a
notification is posted, everything is channeled through a single
method. That is one reason why you typically provide a context object
-- it helps you to identify why you're getting a change notification.
(*) observeValueForKeyPath:ofObject:change:context:
(**) From the "consumer" perspective; from the implementation
perspective clearly there's another major difference in that change
notifications are sent directly without requiring a notification
centre.
For more details about the interaction of technologies in bindings, see
<
http://developer.apple.com/documentation/Cocoa/Conceptual/
CocoaBindings/Concepts/HowDoBindingsWork.html>.
I think that we need more KVO examples without bindings. I'd be
interested to see what applications of KVO are possible without
bindings, or if KVO was really just a solution to a problem in
bindings (in which case, maybe there is a less obscure solution?).
Aaron gives a good example of using KVO to support undo management (see
Chapter 7 of "Cocoa Programming for Mac OS X"), I'm sure there will be
others.
Still, the NSObjectController and NSArrayController classes tend to
work best in specific types of environments, and the amount of genius
required to adapt them to atypical situations seems to be exponential
to the atypical-ness. They are really hard to subclass, I find.
In what sense hard to subclass? There are a couple of clear "choke
points" for subclasses -- newObject to customise the creation of a new
object, and arrangeObjects: for sorting/filtering. You might also add
logic or variables to support other behaviours. There are a couple of
examples at:
<
http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>
(notably the last three or so).
The extent to which one is asked to trust in the frameworks is much
higher, which is disconcerting at first (OK, still is).
That's a common experience. Unfortunately there's probably little that
can be done about that -- since of course the goal is to provide as
much built-in functionality as possible... you'll have to trust it to
get it!
Well at first I was perplexed by the exceptions until I noticed that
the Run log was spitting out the problem with my use of incorrect
keys.
These errors probably account for a significant percentage of problems.
Getting into the habit of reading the error messages is a good
thing...
I have been left confused by behaviours that simply don't make
sense to me, based on what I would have expected. Again, this is when
trying to subclass.
... that said, the greater degree of abstraction afforded by bindings
can certainly make tracking down problems more difficult in more
complex situations. As with many other things, it's a trade-off...
mmalc
_______________________________________________
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.