Java Swing Application with a JTree - MVC Design: Where to position a TreeModel object architecturally?

Question

Please excuse the verbosity of this question, as in writing it I am attempting to think through my design problem!

I have inherited a Swing application which requires re-architecting into an RMI application. The customer requires the Swing GUI to run locally and communicate via RMI to a remote Server process, which encompasses a Controller class which directs calls to sections of business logic and back end database persistence when stimulated by EventListeners, which bridge the gap between the Swing Client and the Controller.

I am to implement an MVC design to allow for new Views to be developed for use with the server.

Currently, the Swing Client GUI contains a JTree which is populated using a DefaultTreeModel. This Model is constructed using DefaultMutableTreeNode objects which are populated with Business Object state via a BusinessObject mapper that sits between these objects and my Data Source.

I have no problem understanding how the Client and the TreeModel are linked: I have established a TreeModelListener to look out for changes to the TreeModel. If the TreeModel object changes, I redraw the JTree by calling its treeHasChanged() method.

However, I am having a headache trying to picture what process would stimulate the TreeModel, so that its contents are repopulated with the latest data in the database, which would in turn invoke my TreeModelListener to update my GUI's Jtree. Who should "own" the TreeModel? Should it be a Class in the model which makes up a piece of the Controller's state? Should the Actions in the Controller by the GUI's EventListeners make a hard call to run a routine to refresh the TreeModel?

Or alternatively is the TreeModel an extension of the GUI Widget, in which case it is a View component? If so, what would be the proper manner in which to invoke a refresh of the state of this object?

I should probably note that I have been thinking in terms of Observers and Listeners in recent days, so I am probably guilty of trying to invoke behaviour to occur off the back of an observer firing.

Yours, very confused!

Answer 1

I got my head around the problem.

I have decided it is a bad idea for Swing API to be present in the Model of my application, since my application is one which can take many different types of UI's (Headless, Swing, Web).

Thus I have decided that the correct approach is for the TreeModel object to live in the View, and be populated by a View Helper which provides access to a generic presentation of the Model tier to any interested UI.

Answer 2

I'm not sure if you decribed about AbstractTreeModel or DefaultTreeModel, I think that this article Understanding the TreeModel is still best around, and link to the JTree tutorial

for reall help you have to edit your question and post image of your headache in the SSCCE form, here are tons of good bases for creating SSCCE

Answer 3

In addition to @mKorbel's informative links and @Shakedown's comment, consider using SwingWorker to periodically rendevous with your middle tier and update your TreeModel, perhaps in response to a Timer. There's a related example here; note that the GUI remains responsive as the query runs. Of course, it's up to your application how often the update needs to run and how frequently you update the GUI.