Link to home
Create AccountLog in
Avatar of deleyd
deleydFlag for United States of America

asked on

MVC - where does View 'logic' go?

Model-View-Controller.

I have a Menu, consisting of MenuItems, and I want to display this menu, and keep track of the "currently selected menu item".

So in the Model I create a menu and some menu items, and put the menu items in the menu, and the menu keeps track of the "currently selected menu item".

However, the Model starts making assumptions about the View: How many MenuItems the View can display. And the View code starts making assumptions about the Menu: How many MenuItems there are, and what type of MenuItem each MenuItem is.

So I start to think all this really should go in the View. The View determines what gets displayed and how it's displayed.

But then I have the View keeping track of what the "Currently selected menu item" is, and the controller asking the view what the "Currently selected menu item" is so it can decide what to do based on that information, which doesn't sound right either.

So either the Model knows a whole lot about the View, how large the screen is, where everything is positioned on the screen, what the currently selected item is, which tightly couples my Model to a particular View;

Or the View determines what gets displayed on the screen and how everything is positioned, but also ends up keeping track of the "currently selected item", and a bunch of logic migrates to the View where I don't think it belongs.

Who should keep track of the "currently selected menu item"?

If I have a Model of the screen, how big it is, and where everything is displayed, then how do I decouple that so the Model doesn't care so much about the View?
SOLUTION
Avatar of kaufmed
kaufmed
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of deleyd

ASKER

So if the user presses the DOWN arrow to move to the next MenuItem, who handles that?

The Controller gets the message that the user pressed the DOWN arrow key. Overall we know this means we should move to the next "currently selected menu item".

Someone has to know what the currently selected menu item is.
Someone has to determine what the "next" menu item is.
Somewhere is stored a "list" of menu items for this particular view.

The data is still stored in the Model. However, "menu items" is sort of a metadata thing.

If "menu items" are a View thing, where the View gets to decide what to display, then the View is no longer dumb but gets complicated, keeping track of of what the currently selected item is, defining what the next selected item will be.

But if I have a model for the screen, then that model is specific to that screen.

Perhaps there are two models? One for the data, another for the specific screen? In which case do I create different screen models for different screens, one for large screens, one for small screens, which in turn can display many menu items, or just a few menu items?

Then I have a "screen model" asking the "data model" for data, formatting that data for display on that particular screen? So "screen model" is tightly dependent on a particular screen?
Are you writing a web app, or a "windows" app?
Avatar of deleyd

ASKER

Windows Forms.

(Actually, unmanaged C++ application, which we test with Windows Forms.)
SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of deleyd

ASKER

If the menu is defined in the controller, then does the controller know about the specifics of the screen size? Such as how many lines of text the screen can display?

(Assume an old fashioned text based screen.)

Then that controller would be specific to whatever specific screen size it was written for.

Then, if later I have a new screen size, I need to write a new controller for that new screen size? And I rewrite the menus all over again?
ASKER CERTIFIED SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account