GUI
The purpose of a GUI to is to allow users comfortable access to a business model. To make it easy it should be intuitive, visually pleasing and of course do the job at hand correctly and robustly.
Aspects
Visuals
standardized for quick recognition (a button always looks like a button and conveys the intended usage of clicking). To make them easily recognizable they are similar in size, border, font, color... the details about this are decided "somewhere", in Swing it's done by the LookAndFeel, in AWT it's done by the OS... Developers rarely have to change these properties on a per-instance base.
To distinguish individual elements of the same category from each other they have properties like text, icons, toolTips - these give hints as to what exactly the elements are doing. They are set on a per-instance base not only at start-up of the UI but probably later on as well, f.i. when switching the Locale
Layout
location, extent, alignement of visual elements, grouping - this should be done with the help a LayoutManager which is powerful enough
Data
Binding - the input elements are representations of some properties of the buisiness data, both have to be kept in synch. [TBD ...]
Validation [TBD ...]
Enabling/Disabling [TBD ...]
Developer's Perspective
Most often the third aspect is in the center of the developer's attention - to get it right guarantees the correctness and robustness of the programm. The first two tend to take a lot of time and are potentially boring (speaking of my experience of course) tasks. They are repetitive but nevertheless difficult to automate (no, I don't like code generating tools...) Furthermore, even with tools it's often difficult to react to users'/clients' eternal wishes to minor changes ("just a bit more to the right, please")
Ideally data wiring should be independent of visuals/layout which in turn should be independent of each other and re-usable across different widget toolkits. One way to reach this goal (or coming nearer at least) is to formally decouple the parts of the view that are describable indepent of any concrete widget elements (everything that's yellow in the diagram) from those that need knowledge of the element's type (everything that's blue).
Visuals
Presentation/PresentationDescription represent the individual visual properties of each widget (item 2 above). They should be readable from ResourceBundles or similar sources which can be created by no-programmers (f.i.translators). In Swing the Action values are a good approximation of the properties that could be included here. At runtime a toolkit specific UICustomizer reads the properties and updates the components accordingsly
Layout
LayoutDescription/Constraint represent both generic type and layout properties of each component. At runtime, the UIBuilder delegates the creation of components to a UIFactory and fills the container using the layout properties so that the LayoutManager can do its job. The UIBuilder effectively decouples the layout from the widget toolkit and has the potential to decouple the LayoutDescription from any concrete LayoutManager as well. The widget specific UIFactory maps the generic type information to an appropriate component (so its coupled to item 1 of visuals above).
Data/Events
[work in progress...]
[TBD: visualize]
JGoodies Binding is a powerful framework to base the binding support on. BeanBinding is the glue to bind named components to bean properties as vended by a JGoodies BeanAdapter.
At some point the actual binding requires knowlegde about the component type. A BindingHandler is responsible to handle these type-specifics, typically there is one type of handler for each component type/group of similar component types. Additional binding information is passed around as BindingMetaData. BindingMap is used to choose a fitting type of BindingHandler for a given metaData object.
Actions: delegating scheme factored into "presentation aspect" which is filled during customizing (or later) and a "command aspect" which is the hook for application code to provide custom behaviour. ActionFactory keeps references to all registered actions.
EventHandlers: done in code, require knowledge about component type. Component can be accessed by name in a given container.
Enablement state: done in code. Currently has minimal support only. BeanBinding provides a hook to couple enablement of a collection of components to the selection state of an AbstractButton. Labels follow the enablement of their labelFor component.
Validation: not yet supported