Model/View/Controller with Win32

honestly, i don''t see the benefit of separating view and controller. input, as i see it, depends on how the object is shown. can you write a controller without knowing anything about the view?

quote:

---

Original post by niyaw
honestly, i don''t see the benefit of separating view and controller. input, as i see it, depends on how the object is shown. can you write a controller without knowing anything about the view?

---

Yeah. You could have an app that accepts input from the console and changes GUI elements in response to events. That is what I learned from digging stuff up. I will probably associate the two and simply reflect GUI events to the Controller class to handle the processing.

"can you write a controller without knowing anything about the view?"
-Nope. That''s impossible. ... if you mean just knowing the interface (not the implementation... aka black box?) then it is possible.

quote:

---

Original post by antareus
You could have an app that accepts input from the console and changes GUI elements in response to events.

---

agreed; i certainly didn''t think of this. so, mvc makes more sense when input and presentation are physically separated. however, in an architecture that ties input and output together, such as windows gui, docview makes more sense.

quote:

---

Original post by DerekSaw
if you mean just knowing the interface (not the implementation... aka black box?) then it is possible.

---

no, i meant literally no dependencies between controller and view.

quote:

---

Original post by niyaw
no, i meant literally no dependencies between controller and view.

---

That''s not MVC. MVC goes like this:

              |-> view
controller----|
              |-> model
 

In fact, in a system of objects, two objects cannot interact if there exists no dependencies between them.

---

For those who believe in God, most of the big questions are answered. But for those of us who can''t readily accept the God formula, the big answers don''t remain stone- written. We adjust to new conditions and discoveries. We are pliable. Love need not be a command or faith a dictum. I am my own God. We are here to unlearn the teachings of the church, state, and our educational system. We are here to drink beer. We are here to kill war. We are here to laugh at the odds and live our lives so well that Death will tremble to take us -- Charles Bukowski

i was picturing something like this. the model links view and controller together, but the latter two don''t theoretically need to know anything about each other.

I think I'm starting to understand.

I am finding the more time I let this concept rest in my subconscious brain the more sense it makes. Trying to break out of the "your controller is bound to your view" is difficult at best and I've never even used them. Here is where I am today:

The Controller doesn't know that the listbox containing 3 items was changed, or that it was changed to item 2, which is "www.google.com". It would receive the data that was chosen that was meaningful for the model, probably as www.google.com, or it's IP address.

In conclusion: the controllerneeds to *associated* with the view in a GUI application, but the controller doesn't interpret the raw events that the GUI framework generates (WM_ messages or whatnot, its only interested in the data).

Make sense?

[edited by - antareus on December 16, 2002 2:44:43 PM]

quote:

---

Original post by antareus
but the controller doesn't interpret the raw events that the GUI framework generates

---

who does then?

edit: quote from the page i linked to:

quote:

---

Controller : The user interface presented to the user to manipulate the application.

---

if that's correct, controller does deal with all aspects of input, including handling input events.

[edited by - niyaw on December 16, 2002 6:03:11 PM]

quote:

---

i was picturing something like this.

---

hmm... interesting. What I know about MVC is similar to Arild version.

The way that I use the MVC is that each element depends on each other.

The view does handle input to a certain extent, but doesn''t define any of the ''business logic'' associated with that event. If a user clicks a button, the view of course updates the button so that it looks like it is pressed, but it doesn''t do anything more than pass the information to the controller which decides what to do with it. The view also is dependent on the model, it is the views responsiblity to draw the model, (i.e. the contents of a file in a list box) but not to make changes to it. But it doesn''t just spontaneously draw the model, it recieves the command to draw certain portions of the model from the controller. Technically the view isn''t supposed to handle any of the user input events, but this design pattern was created after the first GUI operating systems, so windows often violates this rule.

The controller itself generally maintains the state of the application, it determines what each button click does, and updates the model to reflect that. It also tells the view what and when to draw. (i.e. passing it a message box) So it basically handles user input, and determines the effect of that input.

Finally there''s the model. It is pretty self-explanatory, it is a data structure that is supposed to effectively model your data in a way that is easy for the controller and view to use.

There are a number of ways for interpreting the MVC, as far as I''ve seen this is the most common.

these can probably explain it better than I can though:
http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html

So basically in a windows application, you can create a controller class and pass all of the windows received input to that. The controller then would tell the model how and when to update, and tell the view what and when to draw. There really is no clean way to do it windows that I''ve seen, you do register a function to handle input when you create a window, and that function should probably call functions in a controller class for user input events.

quote:

---

Original post by Tybal
The view does handle input to a certain extent, but doesn't define any of the 'business logic' associated with that event...So basically in a windows application, you can create a controller class and pass all of the windows received input to that.

---

These statements seem to contradict each other. Would the controller just take the data received from it like I was saying earlier, or would it interpret raw WM_COMMAND messages? It seems like the latter would bind the view to the controller too tightly.

Are there any other good GUI app patterns? I've been diggin the Model/View/Presenter pattern as well:
http://www.object-arts.com/OldStuff/Overviews/ModelViewPresenter.htm

[edited by - antareus on December 16, 2002 11:59:05 PM]

Wait, no it doesn''t. I got it now. Controller interprets the input but doesn''t perform actions based on it, as that is for the Model to perform.