Learn Objective-C on the Mac - Mark Dalrymple [57]
To establish a binding, you need to configure at list three things: the controller object to bind to, the controller key, and model key path (all the rest are optional settings that allow you to refine the binding’s behavior in special situations, some of which we’ll cover later). You pick the controller object from the Bind to: popup list, which contains all controller objects that are present in your nib file, including any controllers of your own, any generic controllers you’ve dragged over from the Library, and special controllers like NSUserDefaultsController, which is available automatically in every nib file (and shows up as Shared User Defaults Controller in the popup list). The controller key lets you choose different “aspects” of the model object or objects that a controller provides. For example, NSArrayController, which provides binding access to an array of objects, has different controller keys to provide access to the entire sorted array, or just the current selection. The model key path is a string that is used as a key to get and set a value in the model object.
Figure 6-6. The default “unbound” state for an NSSlider’s Value binding options
So, for your first binding, start off by picking the Shared User Defaults Controller from the popup list. This controller is automatically available in any nib file, though you can’t see it anywhere until you use it in a binding, at which point it appears in the main nib window. Now check the Controller Key combo box, and make sure it’s set to “values.” Then click on the Model Key Path combo box, and type “characterMaxNameLength.” This string defines the key that will be used to store the slider’s value in NSUserDefaults—the user’s application preferences. Press Enter or tab out of the field, and you’ll see that the Bind to: checkbox at the top of the Inspector gets checked. That’s it! We don’t need to worry about any of the remaining controls for now, their default values are fine for our purposes. Figure 6-7 shows what the relevant configured bits in the Inspector should look like when this binding is configured.
Figure 6-7. The completed binding for the first slider
Now select the small text field to the right of the slider, and configure the exact same binding you did for the slider: Shared User Defaults Controller, “values,” and “characterMaxNameLength.” That will make it pull its display value from the same place
(the value for “characterMaxNameLength”) in the same model object (the user’s application preferences). To see a little Cocoa Bindings magic in action now, select File➤Simulate Interface from the menu, click and drag the slider, and watch the value in the small text field update simultaneously. While you’re dragging the slider, its value is being pushed into your application preferences by the NSUserDefaultsController, which also passes the value along to the other object that’s bound to the same key: the little text field. Pretty neat trick! But it’s not a trick at all. It’s a simple example of the dynamic nature of Cocoa Bindings. Using this technology, you can eliminate a lot of boring code from your controller classes, and sometimes get rid of your controller classes entirely, using only Cocoa’s included controller classes instead.
Let’s move on to the next GUI control, the matrix of radio buttons in the middle. Click on the matrix, and then look at the Bindings Inspector, where you’ll see that there is no Value option. For this control, instead of binding a Value, we’ll be binding the Selected Tag attribute, which means that when a user selects a cell, that cell’s tag will be pushed down to the model, and when the Preferences window is brought up next time, that saved tag will determine which radio button is selected. Open up the Selected Tag section of the Inspector, and again make sure that Shared User Defaults Controller is selected, and that the Controller