On 11/12/2009, at 9:35 PM, Christian Ziegler wrote: >> 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.
Well, this sounds like a mistake. Menus are just another kind of view, so it's not clear why you'd arbitrarily separate that out from the rest of your GUI. If you want to organise things into different functional groups for the sake of managing your code more easily, categories might be helpful. In fact menus are typically nil-targeted, which allows them to easily be context sensitive, but this might not be necessary in your case as you don't have multiple documents/windows. But even in a vastly more complex app, menus and other views often end up handled by the same controller. The fact you're running into difficulties with the approach you've got shows that there's a problem with your design. > 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? You have a model, whether you appreciate it or not. Even an app that just adds two numbers & displays the answer has a model which embodies the actual addition. Perhaps the functions you've put in your 'mediating controller' are in fact your model? Sounds like you have something that takes a bunch of input values, performs some computation on them and returns one or more result values. That's your model. It should not know or care about the GUI in any way. Instead, the input and output values are its properties. The controller is responsible ONLY for the mapping between these and the GUI. By binding your textfield and stepper to the relevant input value property that they stand for, they will be correctly synchronised as well as driving that property as they should. Here I use the term 'binding' to mean any means of handling that input, including target/action, not just Bindings. But in this case Bindings would probably be best anyway. --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
