Hello,
I've been writing Swing apps for several years that many people find
elegant. And I teach developers in working with Swing efficiently: how
to structure and assemble applications, how to bind and validate date,
as well as how to find, design, layout, and implement well-designed
screens in Swing.
I'd say there are no "best practices" for Swing available online. And
I doubt that anyone can provide "best" practices, because that would
require discussions among Swing developers and solution providers
about approaches, what works well technically and what is easy to
understand, and work with. Also, best practices would explain who can
achieve what result quality, and they would describe the production
time and production costs; but I could never find these information
online or in a Swing book.
In my opinion, the lack of good practices and information how to build
a Swing app is the biggest obstacle developers face when starting with
Swing. Most developers I worked with were slow in finding design,
implementing layouts, building panels, binding data, handling events,
and arranging the different code parts and code layers. And many Swing
apps I've seen suck; besides their poor visual design they are
difficult to understand and even small changes costs a lot. Typically
developers had no clue where to put what code?, how to separate
concerns?, how to tie things together?, how to work with Actions?, how
to launch an app?, and how to store and restore UI state? Most
developers lack guidelines to follow.
But I've found that the average developer can work well with Swing, if
only taken by the hand - in about 3 to 10 days. Almost all of your
questions can be answered or addressed by code, libraries, the
application architecture, patterns, general programming practices,
well-designed examples, tutorials, etc. I teach a Swing development
process that is built around a 3-tier architecture that seperates the
domain, tool and presentation layers and that is based on a productive
layout system. Even though most parts are done programmatically
developers get results quickly and both the code and visual design
becomes quite consistent. This can boost a developer's productivity a
lot - to the extent that the Swing work takes a significantly smaller
fraction of the project work.
So what can you do? I strongly recommend to study Martin Fowler's
draft for further "Patterns of Enterprise Application Architecture".
I've found that these patterns work really well with Swing and Swing
teams - even for developers that are new to Swing and the Swing
architecture. I'd pick the following patterns first: "Presentation
Model", "Separated Domain", and "Separated Presentation". I personally
favor the Presentation Model (Application Model for Smalltalkers),
over the Model-View-Presenter pattern (MVP). However, MVP is a true
and well studied alternative.
Fowler's patterns can be combined with a 3-client-tier architecture
that scales well for moderately large Swing applications. It consists
of a domain layer, a presentation layer, and a mediating model layer.
I've outlined this architecture in my data binding presentation.
MVP-based apps can be structured in these 3 client tiers too.
A key task for Swing applications is the data binding: how to connect
domain objects and domain object properties to the Swing components.
Basically you can copy your data back and forth, or build chains of
adapters from your domain objects to the UI components. The copying
approach is easy to understand and often the first choice for those
who are new to Swing or data binding; I'd say this is a good choice.
On the other hand, copying makes it much harder to synchronize views.
Adapter chains and automatic or semi-automatic updates can
significantly reduce the amount of code necessary to bind domain data
to the UI. The downside is, that this approach is much harder to
understand. As you've pointed out, Swing provides no great abstraction
for a reusable and flexible model that can be used to bind text
fields; the Document interface isn't appropriate for generic data
access. There are a few libraries available that provide a ValueModel
interface that is just intended to add a generic, powerful, and
flexible model for single-valued data: Strings, booleans, numbers,
dates, etc.
I'm not aware of a Swing book that explains a true Swing application
development process. Ideally such a book would combine the patterns,
architecture, and data binding techniques mentioned above and would
describe how to implement it in Swing. Anyway, there's a 10-years old
documentation for a Smalltalk application development process that
does just that. Oracle's JClient architecture and documentation is not
that complete but may be easier to read for Java developers. I provide
a presentation about data binding that is about the Fowler patterns, a
3-tier architecture and a Swing implementation for these patterns and
an automatic data binding. The tutorial sources of my Binding library
may help you get aquainted with adapter chains and the ValueModel
interface. The best documentation for the MVP pattern can be found in
the Dolphin Smalltalk docs.
Once you've choosen your architecture and desktop pattern set, you
should address the following more basic Swing tasks: 1) improve the
appearance by choosing a set of professional look&feels appropriate
for your target platform set, 2) choose a layout system that helps you
build well designed and consistent screens quickly, 3) choose a data
validation solution, and 4) grab a bag of solutions for everyday Swing
tasks.
There are a couple of projects that outline a Swing architecture,
address the data binding and typical Swing tasks, for example: Sun's
JDNC, Oracle's JClient/ADF, the Spring RCP, the NetBeans platform. I
provide a commercial suite of Swing solutions that is based on the
open source JGoodies libraries and adds a bag of solutions and sources
for all public JGoodies tools and demos. These sources are intended to
explain how to tie together all issues mentioned above.
Let me add my standard warning about so called "MVC" frameworks. Swing
doesn't use MVC, it uses a modified pattern. MVC is frequently
misquoted and misunderstood - especially in the context of Swing.
Also, MVC is good for UI components, not for applications. Hence I
recommend to look for concepts, solutions, and libraries that reflect
and work with the Swing architecture, not MVC.
The inventor community of the MVC pattern introduced the
ApplicationModel (now known as Presentation Model) around 1993; MVP
followed a bit later. In my opinion these two patterns are much more
useful for Swing than MVC. Recently the environment that brought the
Presentation Model pattern to a larger audience moved on to a new
architecture: "Pollock". Interested readers may google to see how that
differs from the adapter chains that are often combined with
Presentation Models.
Last but not least a personal statement. I can work much better with
Swing than with other toolkits or frameworks I used before; I can do
more with less code, the code is better structured, it's easier to
maintain, and I get results quickly.
Hope this helps. Best regards, Karsten Lentzsch
References: Fowler's further patterns - http://martinfowler.com/eaaDev
Data binding presentation - http://www.jgoodies.com/articles/
Smalltalk app dev process -
http://www.cincom.com/downloads/pdf/AppDevGuide.pdf MVP pattern
documentation -
http://www.object-arts.com/EducationCentre/Patterns/MVP.htm Sun's JDNC
project home - http://jdnc.dev.java.net/ Oracle's ADF FAQ -
http://www.oracle.com/technology/products/jdev/htdocs/905/adffaq_otn.html
Spring RCP project home -
http://www.springframework.org/spring-rcp.html NetBeans platform home
- http://www.netbeans.org/products/platform/ JGoodies Swing Suite - http://www.jgoodies.com/products/index.html
If you don't know Karsten and JGoodies, then believe me, this guy really knows what he's talking about. I warmly recommend to read carefully his answer and the material he posted as reference. More specifically, be sure to check his Desktop Patterns and Data Binding presentation. Surprisingly, I prefer the old version to the new one.
But I can't do a better job than Karsten at explaining this, I can at best paraphrase him. So just read him!
