Well, Gerald, you'd better start working on it.

Like you, I'm coming from an Oracle environment, and as you are fearing,
 I have spent almost a month now building a development environment
that would allow me to do a small percentage of what Oracle Forms allows
me as a developer.  I have almost finished with the GUI, and then I will
start with data access.  Days (when not on the Oracle job) and nights I
have been busy finding small samples on the net to put my thing
together.  I haven't thought of Reports as yet.

I hope for you that I overlooked what you would like to find.  If you
do, you may still tell me, nothing of all I learned will be lost, I
better retain what I learn the hard way.

Until then, Google is your friend, the sun sites, jfc unleashed, these
newsgroups ...

GeraRd

PS. a MIDI application?  something to do with music?  ;-)

PPS. another friend: http://javaalmanac.com/index.html

I will talk about binding techniques and Swing architectures
in a BoF at the JavaOne. And I provide free presentations and
commercial example applications that help you learn how to
tie together multiple views - regardless whether they are in
different panels, internal frames, or external frames.

The following presentation is about Binding and an architecture:
http://www.jgoodies.com/articles/binding_de.pdf
The English version will be published after the JavaOne.
Anyway, see the diagram on page 81 for my favorite architecture
that covers the problems you mention.

I've found that a good approach is to use the motivation
behind MVC and apply it to the architecture as given in Swing:
separate the domain from the presentation, decouple domain
and presentation, optionally decouple the data models from
the gui models. The presentation mentioned motivates these steps
and explains why you won't find the Smalltalk MVC in Swing.

If you are familiar with Swing Actions, you can do the same
with other model types too. Multiple Swing components share
the same Action; a slight difference between sharing Actions
and plain models is, that the observing components can switch
component properties if Action property change.

Actually the diagram on page 81 does not explictily show
the button's handler that observes Action changes to switch
button properties such as the text, enablement, etc.

At the end of the binding presentation you can find references
that I found worth to read. Most of the concepts are based
on the Smalltalk MVC or vary the VisualWorks Smalltalk application
development framework. If you are familiar with the ValueModel
hierarchy you'll understand most of my Binding presentation.
Oracle's ADF and JClient provide some good material around
client architectures. XMLTalk and the other references too.
I find the Model-View-Presenter (MVP) architecture worth a read
and I often recommend to learn and understand the differences
between MVP vs. MVC+ApplicationModel.

As a consequence of my finding in Swing projects I suggest
that you consider not tying together any Frames, Windows,
InternalFrames, Components, Panels, but the underlying models.
You can then bind Frames and their contents to these models
and share them if necessary. I advocate to operate on models
in a separate model layer, primarily because that seems to
work well in Swing teams: developers then understand well
where to put what code, the domain layer is decoupled,
the presentation layer remains simple too, and all the complex
operations and the biggest portion of the event handling is
located in the middle model layer.

I provide an API and library that helps you decouple the
layers mentioned above and that helps implement bindings.
If you don't want these information, you still may consider
reading about it and learn about the problems I address
and the different concepts I found worth a look.

Regards,
Karsten Lentzsch