1

The scenario: Having a Controller that controls a view composed of complex subviews.

Each one of those subviews is a separated class in a separate file. For example, one of those subviews is called ButtonsView, and has a bunch of buttons.

The Controller has to access those buttons.

Would accessing those buttons like this:

controllerMainView.buttonsView.firstButton.state();

be a violation of the LOD?

On one hand, it could be yes because the controller is accessing the inner hierarchy of the view. On the other, a Controller should be aware of what happens inside the view and how is composed.

Any thoughts?

3 Answers 3

4

a Controller should be aware of what happens inside the view

No it doesn't. Your buttons should send a command to the controller.

6
  • USing buttons was just an example, imagine that you want to access a view to change a color on it, for example.
    – user48945
    Commented Oct 25, 2013 at 13:56
  • 1
    You also don't do that from the controller. If you want to change an item from green to red, you want to do so because the item's status has gone from ok to bad. The controller doesn't care about colors, it just passes the status object to the view.
    – CodeCaster
    Commented Oct 25, 2013 at 13:57
  • So the controller doesn't how to be aware of the hierarchy of the view?
    – user48945
    Commented Oct 25, 2013 at 13:59
  • Imagine having a textfield, and changing the text from the controller.
    – user48945
    Commented Oct 25, 2013 at 14:00
  • 2
    You also don't change a textfield from your controller, how many examples are you going to make up? :-) In your view, you bind a textbox to a model property, like item.Description. You update the model in the controller and then send it to your view. Your view then renders a textbox for the model's Description property and voilá, there's your updated text.
    – CodeCaster
    Commented Oct 25, 2013 at 14:03
3

The Controller has to access those buttons.

It should not. A controller reacts to user actions sent by the view, then updates the model. So the controller observes the view and controls the model. The view observes the model.

The notifications sent by the view should be related to the model, not the view elements, e.g. "name-changed", not "name text box edited". The controller should be completely ignorant of the view components. This allows the view to change without requiring any change to the controller. It allows one controller to work with different views of a model.

Dependencies:

Controller -> Model, View
View -> Model

Control flow:

input event --> View -- view event -> Controller -- model change -> Model -- update notification -> View

If you compose a view from sub-views, then the containing view should collect the notifications from the sub-views and, if necessary, translate them to a higher-level event and notify the controller:

input event --> SubView -- sub-view event -> View -- view event -> Controller
1

While agreeing with the other answer so far (aka "yes, so don't do that") I'd add that the notion of 'subview' implies the possibility of 'subcontroller', and assert that it's ok for the main controller to know of and talk to the subcontrollers, but only in circumstances where the information/effect communicated cannot be transmitted by (simple) changes the model state.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.