Fwd: How much does NSObject's bind:toObject:withKeyPath:options: do?
Fwd: How much does NSObject's bind:toObject:withKeyPath:options: do?
- Subject: Fwd: How much does NSObject's bind:toObject:withKeyPath:options: do?
- From: Mailing list subscriptions <email@hidden>
- Date: Sat, 23 Sep 2006 18:37:24 +0200
For the benefit of others, I am posting an edited version of a reply
that I received off-list. I can't take credit for this information,
thanks must go to the anonymous helper who sent this to me:
The following is based on reading lots of documentation (repeatedly),
reading posts to this mailing list, thinking and re-thinking,
experimenting and debugging.
Key resource: Reference Library > Guides > Cocoa > Design Guidelines
> Cocoa Bindings Programming Topics, especially the chapter
"Bindings Message Flow", should answer some of your questions about
the (default NSObject) implementation of bindings.
(1) My own experience with binding programmatically is the following:
Typical usage case:
- subclass NSView and NSWindowController, and ensure key-value-xxxx
compliance of the relevant model, view, and controller classes.
- expose additional bindings in view's initialize.
- for these bindings in the window controller's awakeFromNib method
the view's bind:toObject:withKeyPath:options: method is called.
- for the same bindings in the window controller's windowWillClose
method the view's unbind: method is called.
- usually view controllers and model controllers are differentiated,
and view controllers are organized in several layers
(NSWindowController, NSObjectControllers, NSArrayControllers; to keep
everything managable).
For some of my applications it is not necessary to subclass NSView.
But I do it in all cases except the trivial ones in order to have
more control in the development phase.
Important for your question: Until now it has not been necessary to
re-implement functionality behind bind:toObject:withKeyPath:options:.
Exhaustive -- some may say paranoid -- debugging showed me that
everything works fine. All methods for binding, observing, key-value-
access, value transformers, "un-observing", unbinding etc. are called
and look good.
Taking it all together, I don't know if it's always, really *always*,
necessary to subclass. But it's not very expensive, and I have
arrived at a working and reusable approach.
(2) Bindings between controller objects:
These usually occur in my applications. It's what I said above about
the layers of view controllers. I use controllers from Interface
Builder for various parts of a view, and bind these controllers to
content attributes of an object controller, which is a proxy of the
window controller. For this proxy a connection is established from
its content to the window controller. With this approach the window
controller delivers the content for all other view controllers.
All this is, I think, within the MVC paradigm. There is just
substructure in the "C-part".
(3) Bindings between model objects outside of the MVC paradigm:
There have been a few postings by Apple engineers to this mailing
list in the past saying that it is not recommended; one poster
disagreed. My personal opinion is:
There is a purpose for Cocoa bindings technology. It's worth citing
the core statements: "Cocoa bindings is a collection of
technologies ... to fully implement a Model-View-Controller
paradigm ... Cocoa bindings reduces the code dependencies ...,
supports multiple ways of viewing ..., and automatically synchronizes
views ... ... You can eliminate most of your glue code ..."
This incorporates the Model-View-Controller design pattern as an
important ingredient.
If someone wants to use bindings between objects without reference to
this design pattern, then some aspects of the design pattern may not
be necessary any more. But these aspects are implemented and are used
in production code.
Then the question is: is it necessary for *your* purposes to use
everything -- and it's a lot -- that the bindings technology
contains. If "yes" or "it doesn't matter", then ok. Otherwise use
something different, e.g. notifications.
Two design patterns may be of interest (and which are used e.g. in
the more evolved design patterns used by Apple):
- Mediator Pattern: Define an object that encapsulates how a set of
objects interact. The mediator promotes loose coupling by keeping
objects from referring to each other explicitly, and lets you vary
their interaction independently.
- Observer Pattern: Define a one-to-many dependency between objects
so that when one object changes state, all its dependents are
notified and updated automatically.
If bindings is high-tech, then these patterns are not-so-high-tech,
therefore easier to handle.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden