views:

313

answers:

3

My model in my MVC pattern, generates components at runtime and gives them to the View to be displayed on the screen through update() method (you know, model is the observable and the view is the observer). But I also need to add listeners to these components, and the controller has the listener methods (because they say the MVC pattern is like this) and it's not involved in this update process. So I can't add the listeners at runtime, but only in the controller's constructor at startup.

I've got an idea, that is making the controller the observer and then giving the data to the view, as well as adding the listeners. Do you think this would be OK?

+2  A: 

Yup, making the controller your model observer to allow it to update the view would definitively fit, to my mind, in MVC orthodoxy.

Riduidel
are there other ideas? anyone opposing? thanks ridui, by the way.
Halo
The following link might be of interest:http://www.emilmont.net/doku.php?id=java:design_patterns:model_view_controller
James P.
+2  A: 

In swing for example the controller/action listener is the observer for the view (buttons etc) and on invoking the buttons (i.e, when view changes) controller kicks in and interacts with the model and updates the view again (with new model changes)

So what you have suggested in the end does make sense to me :)

Calm Storm
2 is good enough :) thanks and I'm upvoting you guys, maybe you may consider upvoting me, as a mutual benefit kind of thing :)
Halo
+3  A: 

I think that you may have some wires crossed.

  1. The model is observable (check!)
  2. The view is observing the model (check!)
  3. The controller is bound to the view (TODO!)

The #3 means that the user interactions from the view are supposed to invoke a registered listener in the controller class, which then updates the model state.

This is the 'classic' Swing MVC. alt text

A 'modified' Swing MVC (which was recommended by some other answers on this question), has the controller play the role of Mediator.

In this design, the view calls an appropriate method on the controller when the user does actions. Then, the controller accesses the model (maybe updating it). Finally, if the model is altered, it notifies interested listeners (in this case, the controller).

This is a 'modified' MVC. alt text

The second design ('modified' MVC) allows very obvious decoupling of the model and view.

For more info, check out this article about Java Swing MVC. It's fantastic.

Tim Drisdelle
it so happened that I came across a tutorial that put the controller in the center, and bound the model and the view to it. And I followed that example. Wouldn't this also do the job, only with some roles switched to the controller? I would like to go on with this approach if possible, if it's not putting serious limits or sth. Please? :)
Halo
actually this modified view makes sense, keeping the listener methods in the view does seem a neater way. But then why is everybody saying that the view just displays data and the controller really interact with user inputs?
Halo
There are different actions being fired: the view notifies the controller of actions in the GUI, and the model notifies the view of changes. In the 'modified' MVC, the model notifies the controller, which then notifies the view.
Tim Drisdelle
The view *does* simply display data. But it must notify the Controller somehow - usually through direct method calls.
Tim Drisdelle
I'm looking at this tutorial, it is good, but the controller in this one seemed like a very unimportant tool to me, it does nothing special, does it? I mean, we can as well remove the controller and work directly between model and the view, and the implementation wouldn't change much, would it?
Halo
Sure, you can do away with the Controller, but you will be in trouble if desired interaction changes. It's much better to keep your Model pristine and clean (decouple). In these MVC patterns, the model doesn't know anything about the Controller or View - it simply publishes notification to all listeners that state has changed.
Tim Drisdelle
Sorry I couldn't express it well. I mean we could combine the controller and the view, and the model could just do what this view-controller says. that wouldn't make much difference, right?
Halo
In general, you should favour the pattern. It's a pattern (best practice?) for a reason!
Tim Drisdelle
thanks, I mean I'd really like having the listeners at the view side, but anyway, I think I'll leave it (cause it's too frustrating) and refer to the view all the way from the controller :)
Halo
I changed it the way you and that tutorial suggested. It works well at the moment, let's hope it doesn't get bad
Halo