2

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!

kleopatra
  • 51,061
  • 28
  • 99
  • 211
8bitjunkie
  • 12,793
  • 9
  • 57
  • 70
  • 1
    I recommend figuring things out one step at a time, then going back to refactor and simplify/clean things up; you can worry about listeners and keeping things updated later. First off, if you've got a back-end database that you want to expose in a `JTree`, I'd start by creating a `TreeModel` that does only this. The model should never be a GUI widget - that's why it's a model and not a view. – Nate W. Nov 25 '11 at 18:02
  • _If the TreeModel object changes, I redraw the JTree by calling its treeHasChanged() method._ Sounds fishy, no need for manual redraws if the model is implemented/used correctly. Tyically, you need xxModelListeners for triggering additional stuff _outside_ of the xxView – kleopatra Nov 26 '11 at 10:39
  • @kleopatra - The treeModelListener method makes the call to treeHasChanged(). After a night's sleep I believe my question is twofold: (1) - Where, in the MVC packages of my application should the TreeModel live? (2) How should this be invoked so that the TreeModel's state is changed? The listener is already in place to re-draw the GUI tree if the TreeModel changes. This Q is motivated by a desire not to need to expose the Model BO's via RMI for direct GUI reloading. I think I need something like a ViewHelper but the xxxModel swing classes are confusing the architecture? – 8bitjunkie Nov 26 '11 at 11:50
  • Currently I have the TreeModel cited in the Model. I have created a method in my Database Mapper object which returns a fully populated TreeModel. My application's Controller contains a TreeModel which is reloaded using this method whenever an Action that creates new data is invoked. I have subscribed the GUI's listener to the controller's TreeModel. This works, but feels wrong - however the alternative seems to be that the Controller action updates the TreeModel instance located in the view...but according to MVC the Controller shouldn't contact the View - only the other way around? – 8bitjunkie Nov 26 '11 at 11:59
  • I am starting to wonder if I have misunderstood the direct link between a View and a Model in an MVC diagram. Whilst I have read articles suggesting that the Controller doesn't have to be 'the data police', I can't see how, without the Controller being involved, how an action can tell a View to refresh. A class, somewhere, must contain a property (treemodel) which my view can monitor for changes. Perhaps my question is more fundamental than Java Swing and is complicated by my use of Swing's xxxModel objects, given that Swing by design is not in itself MVC – 8bitjunkie Nov 26 '11 at 12:03
  • Swing views (or their ui-delegates) _do_ monitor their respective models and update (f.i. redraw) themselves, no need to interfere - provided the model notifies its listeners as they must by contract – kleopatra Nov 26 '11 at 13:37

3 Answers3

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

mKorbel
  • 109,525
  • 20
  • 134
  • 319
  • 1
    +1 See also [A Swing Architecture Overview](http://java.sun.com/products/jfc/tsc/articles/architecture/). – trashgod Nov 25 '11 at 18:35
  • 1
    Possible [alternate link](http://www.comp.nus.edu.sg/~cs3283/ftp/Java/swingConnect/tech_topics/treemodel/treemodel.html) to _Understanding the TreeModel_. – trashgod Feb 27 '14 at 18:25
2

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.

trashgod
  • 203,806
  • 29
  • 246
  • 1,045
  • 1
    hard to tell what s/he looking for, looks like as interview, not question, +1 – mKorbel Nov 25 '11 at 19:14
  • 1
    That makes sense; see also [The Last Word in Swing Threads: Dynamic Tree](http://java.sun.com/products/jfc/tsc/articles/threads/threads3.html#dynamic-tree). – trashgod Nov 25 '11 at 19:36
0

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.

8bitjunkie
  • 12,793
  • 9
  • 57
  • 70