Christian
Christian
The 'ActionPerformed' method in each nested class, in turn, calls a method within the Controller that corresponds to the pertinent action of the Swing component (e.g. button click).
Regards<br />J.
How does your controller retrieve the values from the View (such as origin and destination for search)?
Your post title is about GUI decoupling, and you described the Controller-View decoupling, but you didn't mention your Model-View communications.
...is your controller class offering all system functionalities? if so, you have
the controller class with more responsabilities than just being a ' controller ', low cohesion to me.
Christian
Regards<br />J.
My inclination is to use the internal reference to the GUI in the Controller to access the data I need. If you have some suggestions for doing this I'm more than willing to listen/read.
I've begun coding for each method in the controller to return an instance of my FBNTableModel where applicable.
...The other solution, perhaps more compromising, is to use public accessor methods in the View, so that the controller can look like this:
String destination = view.getDestinationAirport();
I am not very excited about this. Firstly, returning a table model firmly plants the idea that the view must be a table, which may not be the case at all. Secondly, the controller should not return anything, according to how MVC works. The controller job is to map user actions into business logic.
The controller calls the appropriate method of the model, and it's done. From here, either the model "pushes" the updates to the Views, or the Views "pull" the results from the Model.
Christian
Christian
My opinion is that it is fine to have the following in the controller.
...
frontEnd.numberOfPassengersTextBox.setText("");
frontEnd.bookButton.setEnabled(false);
enablePassengerTextField();
Model: My FBNTableModel
If so, do you have a recommendation for getting around the Controller & Model knowing of one another?
The responsibility of a controller in MVC is to select views, not to monkey with them. For example, if the user clicks a "login" button, it's perfectly acceptable for the controller to intercept the mouse event and to invoke something like loginView.show().
...If you decide to replace JTable with something else to show the flights, only one line of code needs to change in the view
Christian
Given this, the Controller then knows all of the views explicitly? Doesn't that create a (potentially) undesirable dependency?
flightsTableModel.setData(data)
...If you decide to replace JTable with something else to show the flights, only one line of code needs to change in the view
.. In addition to adding the new component to the View. Correct?
Aadhi
Christian
(1a) A Driver class loads the application
(1b) Create instance of the view
(1c) View registers itself as a ModelListener
(2a) An ActionEvent is triggered in the View via user interaction
(2b) Controller intercepts the ActionEvent via hook methods in the View
(2c) Controller retrieves pertinent data (via the reference to the View) to pass to method calls in the Model.
(2d) Controller calls Model methods that wrap an instance of the Data class.
(3) Processing returns & each ModelListener's 'modelChanged()' method is executed to deliver the updated TableModel (since that's the component being used in this example).
Don't get me started about those stupid light bulbs. |