Observable/Observer and MVC

[John Smith]

Hello there,
I have a question about the use of Observable/Observer to implement the MVC pattern:
My model extends Observable and notifies the observers (my GUI) when the model changes (as a result of some action by controller). This part works. But what I would like to do in addition is notify the model when the GUI changes. For example, if the user selects some option using a combo box in the View, I'd like the model to set its corresponding field to the selected option. It seems to me that the way it should be done is to let the controller handle the event (selecting an option), so that the controller can update the model. However, under this scenario, the controller will have to have access to GUI control (in order to retreive the selected value), and I want to keep all the GUI controls private. Another possibility would be to update the model directly from the GUI when the combo box selection changes, but that will defeat the purpose of the controller, will it not?
What is the standard way (if any) to solve this problem in a good OO manner?
Thanks,
Eugene.

[Majid Bashir]

Why does the Controller need access to the GUI control? The Controller should be called from your event listener (ItemEventListener in Java for change of option in a combo) passing the selected value. The Controller will in-turn update the model.
Am I missing something?
Regards
majid

[John Smith]

Why does the Controller need access to the GUI control? The Controller should be called from your event listener (ItemEventListener in Java for change of option in a combo) passing the selected value. The Controller will in-turn update the model.

Thanks for your answer. Would you please add a code sample of how the selected value can be passed to controller? Here is what I have right now:
In controller:

        mainView.originAirportChangedAction(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
// do some action here
            }
        });

In GUI:

    public void originAirportChangedAction(ActionListener action) {
        originAirportCombo.addActionListener(action);
    }

Thanks,
Eugene.

[Reid M. Pinchback]

Originally posted by Majid Bashir:
Why does the Controller need access to the GUI control?
...
The Controller will in-turn update the model.

Your approach is correct if the event contains all the necessary data about the change. For many GUI interactions it is true. It isn't always true if the event has rich data.
In that case I think you'd want to have a listener (e.g. register an anonymous inner class) for the GUI component that caught the event, got the required information, and then called the controller. That way the controller would receive the data without needing to know anything about the GUI.
[ June 28, 2002: Message edited by: Reid M. Pinchback ]

[John Smith]

Your approach is correct if the event contains all the necessary data about the change...

Assuming that the event does contain the necessary data, whow do I retreve that data from the event without referenceing any GUI components. For example, if my combo box selection changed, the controller needs to update the model with that selection, but how do I retreive the selection?

        mainView.originAirportChangedAction(new ActionListener() {
            public void actionPerformed(ActionEvent e) {
// The origin airport changed, I need to update 
// the model from here. But how do I find out 
// the selected combobox option from here
// without referencing that the control is combobox
// (since that control may change later)
            }
        });

Eugene.
fixed inappropriate CODE tag for you
[ July 01, 2002: Message edited by: Frank Carver ]

[Majid Bashir]

Eugene, the concept of having the Controller as the event listener does not seem right to me. The Controller is the point of contact with the domain (business) layer from your GUI layer. Your event handler code should be in the GUI layer itself, where from you will call the Controller passing the appropriate information.
As suggested by Reid you can have an event listener class (not necessarily an anonymous one) which obtains the information from the event object and then calls the Controller.
This also aids in the separation of the View and the Controller as the Controller does not have any code which directly accesses the View.
Comments and corrections are welcome.
Regards
majid

[Mark Spritzler]

Hi guys. I have a question, because this is coming up over at the SCJD. My knowledge of the MVC pattern over 7 years has always been that one class needs to know about the others in order to completely decouple the classes so that you can substitue any Controller, Model, or View.
The controller is that class. hence it's name controller. I Know that there are indirection ways of decoupling further, however it adds extra classes that really don't necessarily help make things easier to swap out and decouple.
Here's my concept.
1. The GUI should know only one thing, how to display. It has Hook methods to hook in any kind of ActionListener it wants. Now this GUI is completely decoupled and encapsulated from any other class period.
2. The Model is the Model and that's all. I am sure we have no argument on this.
3. the controller, the workhorse of it all. It controls the interaction between all three classes. So therefore it needs to know about the GUI and the Models. Using anonymous inner classes "ActionListeners" I can hook my methods in the controller to the actions of the GUI. There is a seperate method in the controller for each action I want to handle. I can chose to only have the controller hook into a couple of the actions of the GUI and not others. I could have a second controller handle the other actions. I can swap out another controller to handle the actions differently, all without changing the GUI. controller is not an ActionListener itself.
Now here is where I think is what you guys are talking about, you can move these anonymous inner class ActionListeners to their own class, that passes the call to the controller, and yes now the Controller doesn't need to have any reference to the GUI. But is this 100% necessary. I mean I can change the GUI that the controller uses, but I could have all the GUI's implement an interface and the Controller has a reference type to the interface, and therefore any GUI of that type will work. Because really thinking about it the methods in the controller are for a specific type of GUI. Meaning a controller for a Purchasing System deals with PO's and won't work for an Adress Book application.
So in all these cases I can swap out any of the three classes without causing any affect to the other two.
Comments.
Mark