MVC: When should the view change itself?

[Flash Gordon]

Hey Guys,

In using MVC, when is it appropriate for the View to change its own status? When is it appropriate for the Controller to change the View?

For instance, lets assume we have a volume slider with those little volume bars that change when you slider (just like M$ media player). When the slider is moved in the View, it tells the Controller to change the volume in the Model. But who's job is it to change the volume bars showing in the View? The View could easily do this on it's own. But is that appropriate? Who's job is it to update the View and when?

[jsebrech]

Generally, you should never have to "explicitly" put the view in the right state. Anything that changes should trigger events or call code automatically that causes the view to update itself.

Whether the view should listen only to the controller or also to the model is a matter of debate, so do whatever seems right to you.

In this specific case, i'd put a volume property on the controller that triggers events that the view's volume bar listens to for updates. After that changing the volume from code or from gui has no influence on your view's behavior.

[Assertnfailure]

http://java.sun.com/blueprints/patterns/images/mvc-structure-generic.gif

The way I interpret it is that the controller is meant to act on behalf of all the views when talking too the model, but also is responsible for controlling the way views are represented (beyond the scope of the views themselves) within an application.

So in other words, if you want to display the current volume, the volume bar should be able to do that on its own based on the model as well as its own internal implementations. If you want to show or hide the volume elements, then, as a single view, the controller can opt to add or remove it from the display list.

However, keep in mind that views in practice usually aren't too reusable outside of the particular project they're built in. Typically, they are rigidly constructed to account for the specific model they are using. Because of this, I would turn the volume element into a UI component that could be composed into a view, rather than being a view itself.

[Flash Gordon]

Thanks for the help guys! I'm really enjoying learning about and discussing all of this OO stuff!

Here is what I got for my design so far:
http://img155.imageshack.us/img155/1308/mvccopyem8.jpg

As you can see, all the UI objects are decoupled from the view, so hopefully I do have that going for me. Or maybe I'm on the wrong track and this isn't really a MVC, I don't know.

I kind of see the volume bars like a rollOver or Press of a button. If you were to dynamically add an effect for when a button in the View was pressed, obviously there is no update from the Model (because we are listen to onRelease) so it can't get that command from there. That leaves to Controller to implement the press effect or the View itself. I would probably make the View responsible for its own actions when the actions don't serve any real purpose except to look nice (as in the volume bars). However, I'm just a noob trying to learn.

What do you guys think of that above paragraph?

[jsebrech]

The end goal of a good MVC is this:
- There are many models
- There are many views, all tied to a particular model. Some views may show the same model.
- There is 1 or more controller, which can move from view to view, and can be used to interact with the view / view's model.

In concrete terms, for an image editor you would have many Image models, many ImageViewer views, some of them showing a different view of the same Image, and a central controller that knows about all the Image instances, and when a view is activated will tie itself to that ImageViewer / Image. The controller does not need to be involved in updates of the model that trigger view changes (although there are people that are of the persuasion that controllers need to shield the model from the view and vice versa).

Now, for a video app things get complicated because I don't know if flash allows you to have multiple views of the same video (haven't used video at all in flash).

You're right when you say that the volume bars are purely aesthetic. All your view should do is listen to the model for volume changes, and send messages to the controller (or to the model, depending on design) to change the volume. Interactions that don't change the model should be strictly within the view (although they may be driven from the controller).

[Flash Gordon]

Well....for the video thing. I actually have the real video inside the model and the model is added to the display list. Since the video IS the actual data in this case, I though that would be okay. The view then is just everything else, like the play buttons, volume, progress bars, etc.... I don't know if that is typical or not. But I do see the video as being the actual data in this case.

thoughts?

[jsebrech]

Yes, I suppose that's probably the best way to organize it. "In theory" though, the model is non-visual.

[Assertnfailure]

Hmm...in the case of the video...I would probably just store the video's URL in the model, and load the video into a view.

Model should never need to be a display object.

Also, one other thing with your class listings...
The view should have no direct association to any controller, but rather should communicate to the controller via events. (Hence the dotted line from view to controller in the image I attached).

What tool do you use to generate your image, by the way?

[Flash Gordon]

Yea I think you guys are right about that. With more thought, i think it could be better organized. NetStream is the actual data (that will be in the Model) and Video is just the display. I'll move the Video class to the View and that will take care of the Model so it is no longer a display object.....i think that will work.


Also, one other thing with your class listings...
The view should have no direct association to any controller, but rather should communicate to the controller via events. (Hence the dotted line from view to controller in the image I attached).
Hmm....are you saying the View should communicate with the Controller the same was the Model communicates with its Views?



What tool do you use to generate your image, by the way?
Photoshop.

[Flash Gordon]

I think i got it. The Controller should be a observer of the View just as the View is an observer of the Model.

I don't have my Java OO book anymore (had to return it to the library) so I can't consult that, but what are the advantages of "Controller should be a observer of the View"?

[Assertnfailure]

well, its cleaner to keep direct associations between classes uni-directional. This helps to keep things more loosely coupled.

It also goes along with a sort of a "need to know" basis approach. The view should not be concerned with what the controller is. All the view has to do is dispatch feedback about what's happening inside it. The controller, on the other hand, needs direct access to the views, because it will probably be the one that will move the views around or enable/disable them, etc.

Views can function without a controller, but a controller cannot function without its views.
Just the same, a model can function without views or controllers.

[Flash Gordon]

Ok, I made the changes so that the view is an Observable and dispatches events when something happens to the View. I'm pretty sure that isn't the way Java Head First Design Patterns taught it and I know Design Patterns AS3.0 shows it like this:

private function onKeyPress(event:KeyboardEvent):void
{
// delegate to the controller (strategy) to handle it
controller.keyPressHandler(event);
}


So I trust you on this one, (plus it seems about 6 and 1/2 dozen of the other to me), but is this still a MVC? Both of the text books taugh it with a controller though composition rather than an observer. Or am I being too anal about the pattern and not realizing the patterns are only a guidline and slight variations does not kill the pattern?

[jsebrech]

The downside to a direct call into controller is that you can only have one controller, and that it must conform to whatever type your view thinks it is. Events offer a more flexible model for interaction.

And MVC is whatever you make of it. Design patterns are guidelines, not rules set in stone.

[Flash Gordon]

Thanks guys, I think I've got a good understanding of MVC now.

Interactions that don't change the model should be strictly within the view (although they may be driven from the controller). Sounds good to me. I think in this case since the objects in the View are display objects the Controller shouldn't trying to dig them out and change their physical appears. I think I going to make your statement a rule: Interactions from the View that don't change the Model should be dealt with strictly within the View

What tool do you use to generate your image, by the way? Just downloaded starUML and going to give that a try.

Thanks again guys for the help!
:)

[Assertnfailure]

private function onKeyPress(event:KeyboardEvent):void
{
// delegate to the controller (strategy) to handle it
controller.keyPressHandler(event);
}


Eww, are you serious? If so, I'd have to slap Joey/Danny upside the head for that one... Even if the controller is composed within the views, the handler method should never be exposed to be called directly.

Actually, a rather clean approach that I've considered using more frequently now is a trick that Michael and Ruben brought up (although I've seen it mentioned elsewhere before): Using event bubbling to pass events from views to controllers.

http://specialrelativity.org/blog/2007/08/05/an-example-of-bubbling-events/

[Flash Gordon]

Eww, are you serious? If so, I'd have to slap Joey/Danny upside the head for that one... Even if the controller is composed within the views, the handler method should never be exposed to be called directly. Actually, yea, they are composing the view from the controller ...or was it the other way around....can't remember. But still, that is a copy and paste from the book. I can send you a page or two if you want to check it out so you have something to make fun of them about. ;)

I think i like making the view an Observable; that makes sense.

Thanks guys!
:)

[Assertnfailure]

Composing views from controller is acceptable.
Composing controller from view (if the controller controls said view), is wrong.

[Flash Gordon]

Cool, but I like making the View Observable rather than using composition for the Controller. Seems to make more sense.

Once again, thanks for all the help guys!

BTW, for anyone else. here is what I'm using now for UML diagrams: http://www.owlnet.rice.edu/~comp201/07-spring/info/staruml/

[Flash Gordon]

I'm back, but with a different project I'm using MVC for.

I think I've missed a key point of MVC: I'm not sure why there is a need for a Controller.

For instance, I just built a calendar where I consider the Model to be what keeps tracks of the months, days, and data that populates the View. The View is a group of registered movieclip like so

public function nextMonth(btn:InteractiveObject):void
{
btn.addEventListener(MouseEvent.CLICK, nextClick);
}


The problem I'm seeing right now is currently I just doing this from inside the View and I know it is wrong:

protected function nextClick(e:MouseEvent):void
{
_model.changeMonth(1);
}


I don't see why the View shouldn't directly effect the Model. Why should I further abstract and convolute the process just to keep the OO pattern?

(btw, I'm playing devils advocate here cause I know I'm wrong and I want to better understand. I'm completely open and want to do it right!)

[Assertnfailure]

Nobody's forcing you to use a controller.

Especially if you only plan to have a single view anyway, you can probably omit it.

[Flash Gordon]

ok, maybe for something as simple as this, it is unnecessary.

thanks.

[thatblokemike]

you are using a controller.. your just binding functionality with the view.. its called a "document view implementation of the MVC pattern". the only important part of this pattern is to keep the model, or data seperate from the rest of the application. So you can do this with just 2 classes in this case.. and is probably more productive in small cases. and easy to refactor should it grow as you only need to seperate any controller functionality into its own class.

[Flash Gordon]

that makes some sense. Thanks a bunch for jumping in on this.
Cheers

[thatblokemike]

tis ok.. id read 2 pages and no-one had pointed out the fundamental importance is that the model is seperate.. and thats the main point of the pattern...

in fact i often use document view implementation.. then from the constructor run 2 methods.. draw(); which sorts out drawing everything to the stage... so essentially a view. then a method to set up the controllers.... maybe an init(), or setUpContols().... and often the latter is delayed by a frame whilst the class instantiates itself.

[Assertnfailure]

well the controller follows the same basic principle...where you're just trying to encapsulate things from the UI....except with business logic instead of data.

Sure, if you weren't already aware that the emphasis was encapsulation, then MVC won't make much sense to you ;)

[Flash Gordon]

The more I work with OO the more I realize how much of an art it is. There are some gray areas as to what should go where. Can't wait to read some more stuff about it....and of couse claim this entire subform as mine!

[Flash Gordon]

Hey Guys,

I keep reading this thread every so often and I final get it now...or at least a good bit more than before.

Just wanted to say thanks again!
:)

[hangalot]

we finaly settled on this design pattern for our view structures

http://weblogs.macromedia.com/paulw/archives/2007/10/presentation_pa_3.cfm

[bowljoman]

I love Objects and OOP. I mean... BASIC was fun and all, with those goto's but Now it is very fun, and yes, a mighty fine art.

I couldn't tell you how many objects I make in a week.

Some good , some pointless. The latest one Im stroking out is derived from Socket and extracts video from the stage and passes it to another external process,a c++ object which passes the video as an object, to another process for .... whatever..... Just because I like objects. ;) I think 7 objects in total are used to convert rgb samples from the flash stage, time them, and alpha blend them onto a streaming web cam.

Anybody need an object they just cant get their hands around?:eek: