I knew I shouldn’t oughter-a-done-it, and I feel a little ashamed inside, but I went ahead andbit the appleused Cocoa bindings.
It was, I confess, a reaction to that terrible feeling you get when you’re faced with creating yet another NSTableView data source and delegate. I just couldn’t face another objectValueForTableColumn:blah:blah:whatever:.
How silly it seems now—what’s one more data source among so many?—but my emotions got the best of me, and I went ahead and created—yes, say it, admit it—an array controller in Interface Builder, and I bound that damn table.
And I liked it!
What Brent is talking about here is a new feature that appeared in Mac OS X 10.3, Cocoa Bindings, which is an automatic / dynamic Controller layer for the Mac OS X Cocoa framework. Most students of the MVC paradigm know that it's often the responsibility of the controller to mediate between the model (data) and the view (usually a user interface). It's an adaptation system - formatting / placing data in a cell, responding to a button click, etc. In a world where everything is done properly, different user interfaces can be placed on the same object/data model: HTML, "Heavy Client", etc.
But often, writing the controller can become tedious. As Brent mentions, writing another objectValueForTableColumn:blah:blah:whatever:
quickly loses its appeal along the way. Often, the controller layer is doing a very repetitive task: responding to a change in one of the other two layers (the view or the model) and propagating that change to the opposite layer. Enter Cocoa Bindings. It's descended from technologies previously used in Apple's enterprise technologies, WebObjects (Web, Java, and Web Services application server) and the Enterprise Objects Framework (a very powerful persistence system, primarily used in object-relational fashion):
Cocoa Bindings is a new set of technologies that snap right into the Model–View–Controller design pattern. It lets you hook up various View and Model objects and takes care of keeping them in sync. It does this by keying in a property name. When a view element is set up with a particular property name and a model object is also set up with the same property name, a binding can be made between the two. This will ensure that a value displayed on screen stays in sync with a particular value in the model.While it's not a groundbreaking technology, it's a nice offering from Apple for their primary desktop application framework. It should make it easier for Cocoa application developers to work on their application models and user interfaces while spending less time doing mundane glue work that fills most controller code.
A problem that Brent has, which plagues many developers, is that this is a feature available in the latest commercial release of Mac OS X (10.3), and he has tried to maintain support at least as far back as Mac OS 10.2. What makes this feature most interesting is that it's a developer-only benefit. I'm sure it helps application users in providing applications that might have a stronger control layer, but for the most part, and end-user does not see this feature. It's a 10.3 feature that's unseen. As a developer, at which point do you take advantage of framework and/or programming language features that may be beneficial to you, and when do you ignore them and for how long? I see this concern and worry all the time and in call camps, from Windows (especially now with .NET and Longhorn technologies floating about) to Python (2.0? 1.5? 2.1? 2.3?) and Zope 2.
Hmm. Anyways, Cocoa Bindings are cool. And more Apple Enterprise (aka, the old NeXT) technologies are finding their way into the desktop frameworks in the upcoming Mac OS X 10.4 in the form of new tools like Core Data. Abstract persistence on the desktop. Nice. Hopefully Core Data is easy to integrate with Mac OS X 10.4's Spotlight search system. Then it really will be a system that can compete with Longhorn's WinFS, which is still vaporware (and still might not ship with whatever ships as Longhorn).