Re: Additional action when a view's value changes (Cocoa Bindings)
Re: Additional action when a view's value changes (Cocoa Bindings)
- Subject: Re: Additional action when a view's value changes (Cocoa Bindings)
- From: Graham Cox <email@hidden>
- Date: Thu, 10 Dec 2009 23:26:06 +1100
On 10/12/2009, at 10:45 PM, Christian Ziegler wrote:
> In the target controller I don't have IBOutlets for those steppers and textfields. Those are in another (mediating) controller. Question is whether there is another way to do this instead of defining outlets also in the target controller. I guess assigning tags to each stepper/textfield and defining an enum for them would be an option?
In general I've found it's a false economy to avoid outlets for all controls - you'll want them sooner or later so may as well give everything an outlet just as a matter of habit.
The target controller should be the controller with these outlets. It's OK to have multiple tiers of controllers, but make sure each one has a clearly defined role. Sounds like you have not defined a clear role for each controller and each is doing part of the job of the other. Multiple controllers would usually be arranged in series, not in parallel.
Don't use tags to identify controls - that's not what they are for and there are far more elegant ways to handle this.
To avoid the problem of keeping a stepper and a textfield in synch, you generally want to include the relevant property of your data model within the complete feedback loop that is created:
stepper -> controller(s) -> data model -> change notification -> controller(s) --> text field
text field-^ |-> stepper
If you organise things this way then anyone else that changes that property of the data model also will cause your UI to update correctly (Undo, for example, or a different UI on the same property). This is precisely what bindings does, but you can do the same using target/action as well though it's a bit more work. e.g. You can set up the controller to observe the property changes using KVO (or some other means, such as notifications or a direct protocol of your own devising) and then respond to those changes by setting the relevant controls' values through their outlets. For new code, bindings is the way to go - it uses KVO internally and is the least work to set up.
--Graham
_______________________________________________
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