Re: Swing application architecture question.

From:

Tom Anderson <twic@urchin.earth.li>

Newsgroups:

comp.lang.java.gui,comp.lang.java.programmer

Date:

Sat, 23 May 2009 23:22:22 +0100

Message-ID:

<alpine.DEB.1.10.0905232312390.11863@urchin.earth.li>

On Sat, 23 May 2009, Lew wrote:

Tom Anderson wrote:

On Fri, 22 May 2009, Daniel Pitts wrote:

I'm starting a new project and was considering several different ways to
model and render my data.

1st way is it to use Swing models directly (TreeModel, TableModel, etc...)
in my domain. This seems like the worst way possible ;-)

The 2nd way is to implement a Swing model interface in a way that wraps my
domain model (eg, write a class MyTreeModel implements TreeModel that is a
bridge to MyTreeLikeStructure). This has the benefits of the data always
being "in sync" because the backing model is my domain model. The down
side is that the threading model for my domain must support the threading
model of Swing. This seems unsatisfactory to me.

A 3rd way would be to have a bridge between my Domain model, and a default
Swing model (eg, has a MyTreeLikeStructureListener which will update the
DefaultTreeModel instance as things change). This seems like the winner,
but I'm not sure about the development overhead in this. Does anyone have
experience with any of the three approaches?

None whatsoever, but here's my opinion:

Go the second way. Find a way to insulate the domain from Swing thread
weirdness.

As you say, the first way is not even worth thinking about. The third way
could be made to work, and would leave the domain clean, but maintaining
two copies of a single state is the kind of thing that always leads to pain
and bugs. Also, does you domain model have event listeners naturally? If
not, you'd have to add them to it to support the synchronising bridge, and
then you can say goodbye to purity.

Threads, on the other hand - famously easy!

So, what's the problem with the threading model? I basically know nothing
about Swing. I know that you have to do all mutation of Swing objects from
the EDT, and that you shouldn't use the EDT to do any long-running work. I
assume that the way a model works is that Swing calls in to get values, and
the model returns them, rather than that the model makes calls into Swing -
is that right? Is the problem then that

Actually, it's more like Swing widgets generate events to indicate desired
model actions and changes, a listener catches the events and calls into the
model via SwingWorker, on a separate thread (via SwingWorker) the model does
its thing and either back through SwingWorker or via InvokeLater changes the
GUI state.

your model does heavy lifting under the hood, and you don't want to do that
in the EDT? Hmm. If that's the case, i think i might have to rescind my
advice, since there's no useful way to turn a get-a-value call into
something suitably asynchronous.

The GUI asynchronously triggers model actions. The model asynchronously
sets GUI state.

Okay. That sounds like it should be fairly easy to do with a stateless
bridge of the kind i advocated - exactly as you say, either entirely via
SwingWorkers, or by using SwingWorker or ExecutorService on the way in,
and invokeLater on the way out.

You have to write a separate class for every call in or out (although they
can be anonymous classes), but i don't think that can be any more work
than creating a full state-replicating bridge.

tom

--
Everyone in the world is doing something without me.