Applying the MVP pattern to JDialogs

Question

I'm writing a Swing application, and further to my previous question, have settled on using the Model-View-Presenter pattern to separate the user interface from the business logic.

When my application starts up, it executes the following code:

Model model = new BasicModel();
Presenter presenter = new Presenter(model);
View view = new SwingView(presenter);
presenter.setView(view);

presenter.init();

which creates the user interface. Events are generated by the View, and delegated to the Presenter. The Presenter then manipulates the Model and updates the View accordingly.

In order to handle some events, I need to obtain further information from the user. In the case of these events, I believe it is appropriate for the Swing view to spawn a new JDialog window.

One line of thinking makes me feel this might be appropriate code in the orignal Presenter:

public void handlePreferences() {
    Preferences prefs = view.getPreferences();
    model.setPreferences(prefs);
}

That is, the contents of each JDialog should represent a distinct object that should be retrieved from the View and updated in the Model. However, this leaves the question: do I create a new Model to represent the Preferences object and a new Presenter for event handling in that JDialog?

It seems to me that creating a new Presenter and Model internal to the original View forces me to do a lot of work that would be harder to port if I wanted to change the UI to use JSF, for example.

Please feel free to add comments for clarification.

Answer 1

My advice would be to think about what these 'preferences' fundamentally are. Are they part of the underlying business logic? If so then they should be part of the model structre. Are they specifying the user's preferred way of interacting with the business data? Then they should be part of the view. That may seem theoretical, but in my experience it saves a lot of headaches in the end.

If you can't work that out then where the preferences are saved gives you another clue. if they need to be saved with the data being manipulated then they are probably part of the business logic. If they are saved in the user's personal preference file then they are not, and should be considered view.

Answer 2

No you don't need another "model" just for the Preferences

Just pass the presenter and the mode as arguments in the constructor of the JDialog. It is easier to program a big Swing application when there is

• 1 model
• 1 controller (which itself may contain smaller ones)
• multiple views (but on the SAME data/model classes)

Note that 1 model != 1 class. The "model" of a Swing application can actually be a "tree" of separate "model" classes that have a common "root".

So in your case you need

"Global" model ->(contains) "Preferences" model.

Answer 3

Although it is not uncommon to have "nested" design patterns it is not necessary in your case. Drawing on the other answers:

Model
 - Contains all the real data, variables, objects
 - knows how to set its stored data values to the new values
 - responds to orders (method calls)
 - has method setPreferences(value1,value2,value3...);

View
 - is the IO for the application, just output and input
 - it can only work on its self, on its state
 - it maintains local variables and objects, eg. it has JButtons, JMenus, int counters ...
 - it is knows how to inform the Presenter of State Change
 - its state is visible to the Presenter, or revealed by method call
 - responds to orders (method calls)
 - knows how to get preferences from the user
 - has method askForPrefs();
 - has method getPrefState();

Presenter
 - Responds to state changes
 - does all the deciding, it tells the other objects what to do (not how to do it)
 - knows when preferences are needed
 - knows where to get new preferences and where to put them
 - has method newPrefsAvailable();

... to obtain further information from the user. In the case of these events, I believe it is appropriate for the Swing view to spawn a new JDialog window.

Presenter - checks the Model, determines new preferences are required
Presenter - this.myView.askForPrefs(); //tells view to ask user for pref values
View.askForPrefs - pops up a JDialog box, retVals stored in the view as a state change
View - this.myPresenter.newPrefsAvailable();
Presenter - responds with this.myModel.setPreferences (this.myView.getPrefState());
Model.setPreferences - changes the stored values to View.getPrefState()
Presenter - checks the Model - determines preferences are good
Presenter - continues on

The JDialog is treated as just an extension of the View,it is a member of the View just like a JButton would be. The model has the authoritative actual preference values, and the view has local variables that represent the state of the JDialog.