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?
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?
ProgrammingC++
Last Comment
sarabande
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Are you writing a web app, or a "windows" app?
ASKER
Windows Forms.
(Actually, unmanaged C++ application, which we test with Windows Forms.)
(Actually, unmanaged C++ application, which we test with Windows Forms.)
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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?
(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
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
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?