Java Gui Architectures

When it comes to Java GUIs, everyone and their brother will tell you to use ModelViewController. Well, if only it were that simple. This page provides an opportunity for anyone to provide an outline for a GUI structure that worked well for them. This should go beyond simple design idioms.

AsynchronousMvc

For testability , I propose using the techniques outlined in TheHumbleDialogBox paper. Basically that ends up making your actual GUI class brain-dead, and you create a fully-tested NON-GUI class. This is a little bit different than the typical swing-based MVC pattern, though it achieves the same results - separation of roles. -- JeffTulley

I just finished reading the TheHumbleDialogBox paper, and its got me thinking about how to code this way in Java. The code I'm looking at is a GUI we've written that views and edits Outline structured documents. We decided to use a JTable to render the body of the document. My underlying data is primarily in the table's data model, but all of the object behavior is in the main JFrame, either in Action objects or in Listener objects. I can and should separate the behavior out more clearly from the GUI, but even if I do most of my bugs center on how my rendering requirements, meaning the GUI behavior dictated to me by my boss, is hard to accomplish because I have to try to use listeners to force the GUI to do nonstandard behavior. I'm having a lot of problems, because so much behavior is implemented inside of the UIComponent, or the JTable or the underlying Column Model, etc. For example, I had to write a listener that listens to keystrokes in the cell editor (a subclass of JTextArea). Whenever a keystroke is caught, and the editor is editing, I have to force it to recalculate the height of that row in the JTable. Really difficult stuff to figure out.

So I have two topics I'd like anyone's thoughts on:

First of all, has anyone used TheHumbleDialogBox concepts in Java Swing, and if so did you use the complex structures JTable and JTree in any of those GUI classes? Again, if so, how did you handle them when it you wrote the GUI view instance that worked with the JTable or JTree?

I can think of three ways of implementing the behavior:

1. Make your smart object a subclass Tree_Model or Table_Model?

2. Use a Default_Table_Model object and Default_Tree_Model object in the GUI view instance. The smart object would then manipulate the default models through accessors and mutators in the view interface.

3. The only other thing I can think of would be to use a dumb model that contained some smart GUI manipulation code.

Secondly, does anyone have a useful means of writing Exploratory GUI Test classes. One of the patterns in TestDrivenDevelopment by KentBeck was using tests to establish behavior in APIs that I didn't write myself. Has anyone done this before?

-- DavidBoyer

In my search for a better method to make java gui's i have found some that I am still looking into, but seem to be good. First we have JavaSwt and jFace, there are several good books on them that claim you will end up with less coding work. Next There is an example mvc from http://www.leepoint.net/notes-java/30GUI/80structure/40mvc.html . This method looks like it may not save on key strokes but does look much less messy then most code made with swing. Lastly the jstaple project another mvc framework. http://www.theserverside.com/articles/article.tss?l=JavaGUIDev. seems to be a automagic binding of the model and view.