Cocoa bindings and reluctance to use NSPopupButon
Cocoa bindings and reluctance to use NSPopupButon
- Subject: Cocoa bindings and reluctance to use NSPopupButon
- From: Johnny Lundy <email@hidden>
- Date: Mon, 19 May 2008 10:00:48 -0400
On May 18, 2008, at 9:56 PM, email@hidden wrote:
Message: 2
Date: Sun, 18 May 2008 20:03:48 -0400
From: Erik Buck <email@hidden>
Subject: Cocoa bindings and reluctance to use NSPopupButon
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Johnny Lundy had a difficult time using NSPopupButon along with
bindings. The struggles are archived via www.cocoabuilder.com for
posterity. Mr. Lundy recently wrote "...I am still very very hesitant
to put another NSPopUpButton on my interface, because of the complete
absence of guidance on how to implement the thing, and the many days
it took to get a single one working, and even now I have no idea why
it works..."
Having just now re-read Mr. Lundy's questions and follow-up, I don't
think he had any problem with NSPopupButton at all. That makes sense
because NSPopupButton is not particularly difficult to use. I think
Mr. Lundy's struggles were all with "bindings." Had I been inclined
to participate in the threads at the time, I would have said the
following:
Yes. The whole purpose of my project was to learn Cocoa Bindings. I
can do the target/action thing, and the IBOutlet thing. I had this
whole project working in Applescript Studio, with about 400 lines of
glue code. A logical next step (!) would be to code it in Objective-C
with bindings, no?
1) Bindings are an ADVANCED technique that was recently introduced and
not yet completely documented.
Boy is that an understatement.
I have concluded that the documentation problem is almost solely with
AppKit and especially IB. Basically, there is no manual for IB. At
least not one that is of any use to even a seasoned programmer like me.
If someone tries to use bindings in a
situation where he/she doesn't already know how to write the
application without bindings, it is a mistake to use bindings.
As I pointed out, I had already written the application without
bindings. All of my previous Cocoa apps have used target/action,
IBOutlets, and glue code. This by the way did not help in
understanding bindings - in fact, the so-called time saved by bindings
is offset by the hours and days of frustration at the almost complete
lack of documentation about that long list of checkboxes and popups
that appear in IB under the Bindings tab. That is the nightmare, right
there. And let's not forget that if an IB object has a cell underneath
the object, then there is a whole separate panel of the same
checkboxes and popups, and the only mention of these in the
documentation is some statement to the effect that "most" of them are
"covered" by the main object.
2) Bindings exist to _reduce_ the amount of Controller code needed
when the Model View Controller pattern is used. Bindings don't
eliminate controller code and can't handle all Controller
responsibilities.
3) Bindings appear to be magic, but they are in fact just an
abstraction that enables reuse in place of commonly re-written
controller code.
I am not under any delusion that they are magic. It may appear that
way to some because the only way to get them to work is to randomly
choose one selection after another in the popups in the Bindings pane
until you find one combination that 1) Doesn't cause the app to just
bounce in the Dock on launch, and 2) Actually loads your popup or
other object with the value of the model object that you wanted to
bind it to.
Why do I say randomly? Because in the infamous NSPopUpButton, there
are Content, Content Objects, Content Values, and Selected Indexes.
Telling the difference between these is not possible without random
trial and error, and even when one combination works, one does not
know why it worked. One thread in CocoaDev just ended with someone
saying "Bind them all to the same thing." LOL - that actually worked.
The documentation for binding an NSPopupButton is not in the
NSPopUpButton class page - surprise! It is in a linked page off the
"Menu and popup programming topics" document. Once there, you find
this gem:
content
An NSArrayController instance that provides the content of the
NSPopUpButton.
Unless contentValues is also bound, the titles of the items in the
NSPopUpButton are derived by invoking description for each of the
content objects.
Great. And this content is what exactly? Strings? Or what?
Then we find below that,
"contentObjects
An array of objects that are returned by selectedObject or
selectedObjects in place of the corresponding content object."
I don't want an array, I want the single item that the user selected
in the @#(#)*# popup!! If "returned by selectedObject" is an array,
how do I know which of the items in the array is the selected one?
See now why people get driven nuts by this documentation?
4) Bindings ARE NOT A REPLACEMENT FOR ALL CONTROLLER CODE, and
bindings are often not the best technique to use.
Mr. Lundy would have been better off writing his controller code
explicitly and using the established outlet, target and action
patterns instead of bindings. Not only would he have achieved
complete control over all aspects of his application's behavior, he
would have gained insight into how, and and why bindings work or not.
Wrong. Understanding target/action is very simple because they make
sense and the documentation is good. But being proficient with target/
action tells you nothing about Bindings. For that you need
documentation on what is the content, what is the content objects,
what is the content values, why is content objects different from
content values, etc. This is so easy to explain - obviously someone
coded it and it's very flexible - why the absolute reluctance to just
document it?
I find that I hardly ever use bindings in my own applications. I am
more comfortable doing things the good old fashion way in part because
I often want very fine control over application behavior. I blame Mr.
Lundy's specific struggles on misguided insistence on using the wrong
tool for the job.
I counsel Cocoa newbies to just forget about the Bindings inspector in
Interface Builder and pretend they don't exist.
As I said, I am not a newbie (except to Bindings), and it does not
help me to be told not to use Bindings in a project whose purpose is
to learn Bindings.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please 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