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: Christian Ziegler <email@hidden>
- Date: Sat, 12 Dec 2009 11:58:06 +0100
On 12.12.2009, at 00:54, Graham Cox wrote:
>
> 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.
Categories is an interesting approach. I have not thought of that yet. Frankly I am a bit spoiled from the iPhone where virtually every "screen" has it's own controller, so I tried to split my controllers up a bit.
>
>> 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
>
>
Well I have a model, that for sure, however I always thought it's more the data you operate on, not necessarily parameters. Also those methods in my MediatingController are pretty much the logic of my app and from what I 've learned, the logic goes into the controller, but maybe im interpreting this wrong. To be a bit more precise, some of the methods in the MediatingController are for updating the view (a preview for instance), some are for updating the model. The latter means I decide what to do depending on the state of the view and do it, whereas "do it" means I call a static method in a different class which does the computation and store the return value in my model objects. Do you still think those methods in the MediatingController are model?
Thanks for your efforts.
Cheers,
Chris
_______________________________________________
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