Applying pure MVC to Swing/JFC

[Reza Rahman]

Does anyone have any experience applying pure MVC to Swing/JFC? Since Swing is so geared towards Model-Delegate, I'm having trouble visualizing how to make a clean separation between the model, view and controller. I apologize for the long post, please bear with me...

I suppose all the state information on the client GUI can be encapsulated into the JTableModel (my model for the client-side app) and I could have it making calls to the database to retreive/update data as necessary.

Similarly, the extension to JFrame can act as the view more or less (see below for the complications with this assumption) and be in charge of displaying the model data and gather input from the user.

I'm planning to create one large, centralized controller (essentially the Super Event Handler) and attach it to every Component that may fire an event (that I care about) in the view. In general, the controller should perform the following functions:

1. Collect user inputs from the view.
2. Ask the model to perform basic data validation and send possible error messages back to the view.
3. Send appropriate "update" commands to the model to repopulate itself through the database. Changes to the TableModel should be automatically reflected in the JTable.
4. Update the view accordingly if necessary (e.g. status messages).

The above sounds good at first blush but has the following problems:

1. My understanding is that in pure MVC, the controller should not depend on the view to get input from the user. Clearly, all Events in Swing get trafficed through individual components to the "super handler", violating this principle. Should I be claiming this is MVC if this is the case?

2. All the data displayed in the view in my case is not encapsulated in the TableModel alone. One example is what happens when the user clicks the help button - I read the contents of the help file, put it into an HTMLPane and open a window. Is this not a violation of MVC?

3. My configuration window is completely separate from this entire Framework since I need it to setup my model using the config before I glue MVC together. Where does this fit into MVC?

Thanks for reading this long and meandering post. I appreciate your input.

Reza
[ February 06, 2005: Message edited by: Reza Rahman ]

[Jeroen Wenting]

3) (and 2) as well in a way) you're thinking too monolithic.
Why not implement each of those separately as an MVC system of its own? Noone tells you there should be only 1 view or 1 controller...

So your HTML pane for your help is a view, the button that launches the help screen calls a controller class which calls a model (say something that holds the data) to fill the view.

The whole idea of MVC is to decouple actions and data.
So your button calls an event handler. That event handler is now your controller for the button event.
If you think that's too closely linked still you can have the event handler delegate the call to something else which then becomes your real controller (if the action isn't just relevant to the Swing GUI that is the preferred way, in case of your help display I could envision it being a component usable in other applications as well, so the event handler would delegate to a method of that component for example).

As to 1), if the controller doesn't depend on the view to get user input, what can it get the user input from?
The view is the only part of the application that ever interacts with the user after all.
What you should NOT do is have the controller directly access fields on the view (so not access the screen controls directly).
Instead the view should pack up the data it wants the controller to act on in some object instance and pass that on to the controller.

[Reza Rahman]

Jeroen:

Believe me, I see your point. It almost feels like I'm "imposing" MVC onto something that does not fit it completely or naturally. Actually, me being me, I investigated further and found this article from Sun on the topic that somewhat explains my quandry:

Swing MVC Architecture

The root of the problem is that most "popular" GUI frameworks like J2SE, MFC and .NET very tighly couple event handling to forms themselves (to make life a little easier on developers). Pure MVC is more viable in environments that are either designed for MVC (e.g. Smalltalk) or where no such tight coupling exists (e.g. the stateless nature or HTTP and hence the struts/FuseBox frameworks for J2EE/ColdFusion).

I think I've come conclusion that I'm going to use one controller as long as it isn't too burdensome, a few models and one view (again, if it is not too awkward). All in all, I'm going to describle my problem in the choices document and call my pattern Model-Delegate (exactly what Sun calls it) instead of MVC.

Thanks for your input.

Reza

[peter wooster]

Originally posted by Reza Rahman:
...
I suppose all the state information on the client GUI can be encapsulated into the JTableModel (my model for the client-side app) and I could have it making calls to the database to retreive/update data as necessary...

This statement summarizes the cause of your problem. The JTableModel isn't your GUI's model. What would you do if the requirements changed to require multiple views, such as a table view and a tree view. The JTableModel is really just part of the table view. The model should be the interface to the database and the controller should mediate between views and the model.

[Reza Rahman]

Thanks, you are right about that. Would you still call the updated framework MVC instead of Model-Delegate though?

[Inuka Vincit]

IMHO the idea of a pattern is to help you to solve the problem (and hopefully simplify it) and not to confine what your doing. The reason I say this is because you seem to be worried about violating the MVC pattern rather than using it as a solution.

THe Model should be the interface to the database like what peter said. I took the approach and then modified it to suit the assignment. Since the only model we were dealing with was data, I created my model using AbstrctTableModel, and then proceeded to build the controller on to it as well. Of course this approach will make it hard to change the type of view in the future, but I documented that. I just allowed for changes in fields and such.

As for configuration, and other features that were not part of the main database GUI I didn�t consider them to be part of the MVC pattern. But I did include them as parts of the MVC classes I had.

Not the cleanest of approaches, but I didn�t see the point of breaking it up some more. I did document the shortcomings. I suggest you do the same depending on the approach you take. I wouldnt worry too much about violating the MVC pattern a bit(configuration, help etc.. ) as long as you have divided up the responsibilities of the objects properly.
[ February 07, 2005: Message edited by: Inuka Vincit ]

[Frans Janssen]

Originally posted by Inuka Vincit:
IMHO the idea of a pattern is to help you to solve the problem (and hopefully simplify it) and not to confine what your doing. The reason I say this is because you seem to be worried about violating the MVC pattern rather than using it as a solution.

Exactly!

Because IMHO the GUI for the assignment is very simple, I made the bold choice not to use any patterns at all, unless "Monolithic" is a pattern too nowadays (I also described my approach as such in choices.txt.)

I must confess that I also could not be bothered to make a fancy pattern-based solution for my GUI. I hope I will soon learn if the assessor agrees...

Frans.