After much research, it came to me that Swing designers had the same question: "how do we pass data from views to controllers so that neither views not controllers are aware of each other?" The poosible solutions seem imperfect, and maybe that's why the Swing
doesn't use controllers, or rather, the controllers and views are one thing. I already submitted my assignment, but for my future projects, I decided that the controller should be used
only to select views, and not to transport data from views to models.
So, if I were to do my FBN assignment again, I would do MVC as follows:
When the user clicks the "Search Flights" button, handle the even in the GUI and invoke a corrsponding business method in the model:
So the GUI has a reference to the model (but model doesn't know anything about the views). Also notice that the origin and destination are passed from the view. But if the GUI controls that hold the origin and destination change (to say text boxes), only View will need to be modified.
In the Model, the searchFlights() method would look like this:
The fireModelChanged() method above is fired each time there is a change in the model that the views might want to know about, and it looks like this:
This is actually very clever (although I didn't invent this), -- all the views will just implement the ModelListener interface which specifies only one method, modelChanged(
String changeType, Object change). Since the second argument is an Object, you can pass whatever information from model to views, yet model doesn't know anything about the views.
So back to the view where we process the notification from the model:
Note that tableModel is the other "model", but instead what it is, -- the table model for the table to display the flights.
Now, I would still use the controller, but only to select the views. This is so that the views don't have to know about each other. For this part, it makes perfect sense to use those callback methods that Mark proposes (since the controller doesn't need any additional information). For example, when the user selects the "Connect to Database" menu item, the controller will intercept the event (as opposed to a business method invoked in the model), and will pop up the connection dialog. But
that's it, the controller doesn't do anything else:
When the user specifies the connection parameters in the connection dialog, the view (the connection dialog itself) handles the event and invokes a method in the model that performs the business method of connecting to db:
Again, if something needs to be updated in the views as a result of connection, the model will just fire the same method to notify the views:
fireModelChanged("connectionEstablished", someObjectWithInfo);
It all now makes sense to me, how about you, ranchers?
Eugene.
[ July 17, 2002: Message edited by: Eugene Kononov ]