(reposted to the list in 2 parts because the whole thing was 1 byte over the stupid limit)
On Sep 8, 2015, at 21:04 , Alex Hall <mehg...@icloud.com <mailto:mehg...@icloud.com>> wrote: > > and too little comprehension of how bindings work I think it’s both easier than you think, and harder. Bindings are not actually very interesting — to use, that is. (Implementing new ones properly is a bit of a challenge, but it is almost never done any more, because bindings are ancient and nearly obsolescent technology. We use them because they work, and because there’s nothing to take their place, but they were designed for the kind of Interface Builder (IB) we had in 10.3 days, or perhaps even further back into the NeXT days.) Technically, bindings are two-way links between two different properties of objects in two different classes. When either property value changes, the binding ensures that the other property changes to match. That’s about it. However, what bindings *are* is pretty much beside the point. What matters is how they’re *used*, and for that you need to keep in mind what IB is all about. IB is a design tool, not a programming language, so is has a lot of inspectors where you can enter information — mostly strings that are *names* representing entities that are present only at run time. In addition, IB allows you to define relationships between elements, sometimes by using controls in inspectors, but often by manipulating a graphical representation of the UI. Incidentally, I know you know all this part, I’m just trying to layout it all out in sequence. In your code, by contrast, you have instances, you have methods, and you have logic, courtesy of the Obj-C language. (Swift doesn’t change anything fundamental about this, so I’m ignoring it.) As you know, you generally have a choice of implementing UI elements via code or via IB, and it’s usually easier to use IB because IB is usually better at expressing UI relationships. That leads to a problem — how do you adapt the pure data you enter into IB at design time to the Obj-C runtime that’s all there is at … well, run-time? The solution is to snap together a series of pieces, like interlocking children’s blocks, with an IB piece at one end and an Obj-C piece at the other. Let’s say the data pieces at the IB end are plastic blocks like Lego, and the code pieces at the Obj-C end are metal components like in an erector set. A binding is a piece that connects one piece to another, sure — see the above definition — but more importantly it’s a piece that *adapts* plastic to metal. Bindings are not the only such adapters. IB outlets are adapters (one way only, metal to plastic). IB actions are adapters (also one way, but plastic to metal). Control delegates are adapters. Table view data sources are adapters. The trick is to find the correct sequence of adapters for each job, and as I said already, these days we mostly just choose from a pretty short list of adapter patterns. Bindings are probably the cleverest of the adapters, and I think the only kind of adapter that’s two-way. So, how do bindings work as adapters? Although bindings are bi-directional, in correct usage we say that a binding connects *from* a UI element (plastic) *to* a data model value (metal). Bindings keep track of a list of property names — at least two, because there’s always a from and a to — which we usually write from left to right, though they're easier to follow from right to left, from plastic to metal. A bound UI element takes its value from the *last*-named binding component, applied to an object whose identity the binding knows. That object is determined by applying the next-to-last component to another object the binding knows about. And so on, along the sequence from plastic until it hits genuine metal. That’s about all there is to bindings, apart from details. As it happens, each UI element can be bound only to certain categories or functions of model object. (I’m not using those terms in the Obj-C technical sense.) IB contains an internal list of what binds to what, and it won’t let you bind things that shouldn’t be bound. You know this list from the popup menu in the Bindings inspector in IB — it’s usually a very short list for any given element. Notice that I’ve said nothing yet about NS…Controller. (For the sake of the current discussion, I’ll just say NSControllers, though the general principles apply to all NSController subclasses, including array controllers.) How do they relate to bindings? In a very real sense, they don’t — they’re something else — they are in fact a separate kind of adapter. Unfortunately, in practice, NSController and bindings are all tangled up together in a confusing mess. Let’s try to avoid the tangle, or the confusion, as long as we can. NSControllers are another piece of obsolescent 10.3-era technology, and I think I should disclose that I hate them with a passion, even as I’m forced to use them. The next thing to say about NSControllers is that they are mediating controllers, as opposed to coordinating controllers such as window controllers and view controllers.I’m going to risk offending purists by claiming that for all practical, modern purposes there’s no value in thinking of them as controllers at all. What they are is black boxes filled with glue. As I said, they’re also IB adapters, so you use them in chains of adapters. The usual configuration (from left to right, metal to plastic) is metal(model)-NSController-binding-plastic(UI). There’s often an additional binding (model-binding-NSController-binding-UI) and the exact sequence varies according to UI element type, but these are the basic two patterns. In the first case, the array controller is “connected” to the data model (implemented via NIB-loading machinery); in the second, it’s “bound” to the data model (implemented via a binding). (continued in part 2) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
