mvc question

James Du

Ranch Hand

Posts: 186

posted 14 years ago

hi, ranchers, there's one thing here i cant work out: when the linstener method in the controller revoked, how does it get the component value stored in the gui , does the gui provide the public field or method for the controller to do that ? Regards James

The controller knows about the GUI, so therefore can get any value that is on the GUI directly.

Mark, I was wondering if there is a cleaner way to do this, for example defer knowledge of GUI values to a Mediator. So the controller job is to process the events, and if controller needs to know about some GUI values, it will ask the mediator to get those values. So in the controller, you can do something like this:

Eugene.

Sai Prasad

Ranch Hand

Posts: 560

posted 14 years ago

Eugene, Controller is the mediator between the GUI and the rest of the RMI world. There is no need to have another mediator between the controller and the GUI. When you use the Mediator pattern it is always preferred to have a tight coupling between the controller/mediator and the GUI. In this case, I recommend keeping all the members of GUI private. Controller can access the values in GUI only using accessors.

John Smith

Ranch Hand

Posts: 2937

posted 14 years ago

Sai wrote: There is no need to have another mediator between the controller and the GUI.

I misnamed Mediator, -- it should actually be Model, for a complete MVC pattern: -- In GUI, all controls are private, it knows nothing about Controller, and keeps a reference to Model. When GUI controls change, GUI updates the Model. GUI actually implements Observer, so that it can update in response to Model change. For example, if in the "Seats To Book" text field the user types a number greater that the number of seats left in the table, the model can set its boolean field bookingAllowed" to false. This will update the GUI (make the "Book Flight" button disabled). -- Controller only calls the public methods of GUI to register the action listeners, it knows nothing else about GUI. If controller needs some values from the GUI, it would call the corresponding accessor methods in the Model (not the GUI). If instead you call the public methods of the GUI to get the values, your controller is too tightly coupled with the GUI. -- Model holds all the values and has a set of get/set for each control. Model extends Observable, and notifies the GUI of the changes in the model. How's that? Eugene Kononov.

Eugene, Looks good. I didn't do it this way and I don't know if anyone has done it. Having a tight coupling between the controller and the gui is fine and that is how the mediator pattern is supposed to work. Also in the mediator pattern, it is preferred to have the controller get notified about changes to the gui values. In your case, your model is getting notified instead of the controller. I don't know how the grader will look at it. I guess you have to justify for the extra Model class instead of keeping the model in the controller.

John Smith

Ranch Hand

Posts: 2937

posted 14 years ago

Mar wrote: Model is your access to the Data class.

Actually no, the model just holds the state of the application (origin airport, destination airport, seats to book, etc). And it has setters and getters to manipulate the application state. The access to Data class is provided to Controller by what I call a FlyHighDataService class (wich I consider a facade to data aceess). So, my book() method in Controller looks like this (notice that controller actually holds reference to table model and application model):

Hi Actually the on getting some cue from the GUI (View) the controller updates the Model. The controller acts as a a mediator between view and the model, thus mediator pattern. The moment the model changes its state the view comes to know about it, as it has subscribed itself as an observer. thus, Observer pattern. you ofcourse need not implement these patterns urself as they are inbuilt into the swing components Regards Arup

John Smith

Ranch Hand

Posts: 2937

posted 14 years ago

Actually the on getting some cue from the GUI (View) the controller updates the Model.

I don't understand what you are saying here. The question is, if controller needs some GUI values before it processes some action, how does the controller get those values without referencing GUI? For example, if the user changes the selection in the "Destination Airport" combo box to "Mumbai", and then clicks on the "Search Flights" button, the controller can process the event (search the flights). But before it does, it needs to know the destination airport. And we don't want to see something like this in our controller:

To avoid this in my Controller code, I make a callback to an updateModel() method that is defined in GUI. Over there, I update the model with selected origin and destinations. Now, the controller can get these values from the Model. However, I don't like this implementation either, as now GUI knows about the model and can manipulate it bypassing the controller. Any other solutions? Eugene Kononov.