On 10.12.2009, at 13:26, Graham Cox wrote: > > 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.
Well in general I usually have a hard time defining roles for my controlers. At the moment the idea is: I got one controller for all actions triggered by the mainMenu, one for all actions triggered by gui elements (my app only got one window) and another one for the rest of the logic. My problem was, that either menuitems and gui elements trigger certain actions which need to read values from many gui elements, so I introduced this mediating controller, which is not target for any action but knows all views via outlets. Also the MainMenuController and the MainWindowController got references to the MediatingController, so they can invoke methods. > > 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. The thing is, I don't have a model for those values because it is a one way street. I only have to read the values to compute stuff, but never have to set new values programatically. Also there is no persistince. Would you still write a model? > > --Graham > _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
