Project VRE is an effort I've undertaken to improve the process of developing
and maintaing user-interfaces in Swing. VRE stands for Visual Resource Editor.

What's the problem?

-- Swing is too hard --

Swing is difficult to grasp and use. It fails to define any reasonable means
of maintaining a separation between your application and UI code.  This
separation is important for several reasons, one of which is that it allows
for the proper deployment of specialists on your staff.

It's resource model is weak, being defined in terms of more Java code.
Resources are not code.

Swing's look&feel plugability confuses such matters as setting a component
foreground, background, or font.  If I call JLabel.setBackground, why doesn't
it seem to apply?  It could be because the l&f has overwritten the value or
because the l&f has deemed that all labels are Opaque, meaning they don't
paint their backgrounds, so as to seem transparent.  [Aside: Why the term
'Opaque' and not 'Transparent'?]

Challenge: craft a look&feel independent JComboBox that doesn't respond to
mouse or key event.  You won't be able to do it because the various look&feels
add mouse listeners on the various sub-elements.  You would need access to ALL
the available l&f implementations to accomplish this.

-- Hand-coding layouts is no good

Writing Java code to layout components in a container is time-consuming,
error-prone, and often results in UI that violate a primary tenent of
Java, cross-platform transparency.  People who use GridBagLayout and specify
a certain inter-component separation, for instance, are hardcoding a value
that only the l&f should know.

-- The right person for the Job

The person who designs your application UI should NEVER write any UI code.
It's the concept of specialization that is so embraced in the webapp world
with HTML jockeys using JSPs, calling into EJBs developed by the business-
process experts.  Your UI designer should be able to concentrate on her
primary task and not why JLabel.setBackground doesn't seem to work.

-- Localization is for more than strings

If you can factor the UI away from the application code and into a resource
file, you can provide locale-specific versions of the same core resource file.
Further, it may often be necessary to alter the screen layouts for a
successful localization.

What do we need?

The View (no, not the TV show)

The late Galaxy Application Environment sported many important features,
a few referred to above.  In short, you created a platform independent 
resource file that is in effect a data dictionary containing all your
application resources.  A resource describes the attributes of a Java
Object, implementing the Loadable interface.  The set of Resources is
extendable.  There are built-in Resources for:

Dictionary
String
Boolean
Integer
Double
Font
Rectangle
Color
KeyStroke
.. arrays of the above

Dialog
Container
ScrollPane
Label
Button
TextField
TextArea
ComboBox
CheckBox
List
TabbedPane
Table

-- Springs and Struts --

Of key note is that the Container and Dialog classes, and their associated
editors, implement the Springs&Struts layout model.  Springs&Struts allows
the UI designer to craft complex layouts via a drag&drop metaphor.  Each
DialogItem has connections extending out from each of its edges, as well
as two internal connections that determine the items dimension.  A connection
can be either a fixed-length, a spring, or combination where the spring can
only compress down to the fixed-length, called a fixed-base.  As well, a fixed-
length connection can be a natural-length connection, meaning that its size
is determined by the current look&feel.  Each and every other existing
layout manager can be represented by a SpringLayout, although that may not
always be practical.  Pre-built SpringLayouts that emulate GridLayout and
BorderLayout will be provided.

The version of Swing shipping with JDK1.4 includes new SpringLayout classes
but without tight tool support, they probably shouldn't be bothered with.

How do you use it?

Say you've used the Visual Resource Editor to create a resource file Demo.vr
that contains a single Dialog resource named "MyDialog."  The code to get that
Dialog onscreen is:

package demo;

import appframe.*;

public class Demo extends ApplicationManager {
  public Demo() {
    super();

    DictionaryResource topRes    = getResources();
    DialogResource     dialogRes = (DialogResource)topRes.find("MyDialog");

    new Dialog(dialogRes);
  }

  public static void main(String args[]) {
    new Demo();
  }
}

The View is in a resource file, created with VRE.  The Controller is your 
application.  The Model is provided by pre-build data-access classes, reaching
out to webservices, EJBs, or any other remote state.  This framework supports
MVC wherein each facet can be separated out completely.  Don't combine your
View and Controller.

The Controller

So, you've done some cool cleanup of you application.  Now what?  You need to:

 _ bind your application model to your UI components
 _ listen for user-initiated changes and act on them
 _ maintain state regarding what is modified and persisting those changes
   at the appropriate times

This is the code you need to write.  Basically, your "Listeners" live here.
Your controller listens to commands issued by the View components, and responds
as appropriate.  Often your response will entail applying a new Model to
a component.

The Model

Initial UI models will be of the static variety.  Additional model-
types, such as JDBC-, EJB-, or WebServices-based, will provide simplified
access to remote state.

I'll implement these advanced models last.

I want to make it easy to create and maintain Swing applications and Applets
following well known best-practices.

Gary Keim
garykeim@pacbell.net
12/31/02