Introduction

Mission

The goal of the spring-richclient project is to provide a viable option for developers that need a platform and a 'best-practices' guide for constructing professional Swing applications quickly.

Specifically, spring-richclient seeks to:

Provide an elegant way to build highly-configurable, GUI-standards-following Swing applications faster by leveraging the Spring Framework and a rich library of UI factories and support classes.
Foster integration with existing rich-client-related projects where it make sense. For example, jgoodies-forms and TableLayout are two good layout managers. We don't need to develop another one.
Adhere to the principles set forth by the Spring Framework--programming to interfaces; the importance of sound OO design, documentation, and testing.
An action framework that provides centralized configuration of Swing actions and appropriate handler registration based on the current active view. Action configuration, as well as action bar contribution policies (to menus or toolbars), can be defined centrally and externalized in Spring bean declarations.
Support for multiple window management, page configuration, and view management. The concepts here are inspired by Eclipse's perspective/view constructs. Views can be defined in the Spring container, associated with one or more pages, and a default page can be configured to be loaded at startup.
Common support classes addressing various rich client requirements including: well formed dialogs, wizards, input validation (typing hints and validation results reporting), button bars, internationalization, image/icon caching, progress monitoring, UI threading (classes cleanly promoting responsive UIs), tree table/property sheet, table sorting/high-volume table updates, GUI standards builders/helpers, help/about, etc.

spring-richclient adds value for people needing to develop Swing applications and do so in a way that promotes consistent, well-designed, configurable Swing applications. The spring-richclient developers strongly feel the "old days" of Swing apps "not looking native" and not being performant or web-accessible are gone with JDK 1.4.2 and 1.5 and webstart. It is our belief the only problem with Swing is there are a limited number of higher-level abstractions available that assist in making the toolkit simpler and easier to use, and a limited number of design best practices. The goal of spring-richclient is to provide that.

Background Information

Platform Overview

There is one Application per VM
There are one or more ApplicationWindows per VM. Each window is realized by a JFrame component (which it acts as a factory for creating)
There is exactly one ApplicationPage area for each window. Each page has a singleton ApplicationPageDescriptor, which encapsulates rules on how to initially layout that page using the ApplicationPageLayoutBuilder (this interface is really bare right now) In the future, we want to support declarative layout policies and remembering custom (changed at runtime) layout settings: e.g page-specific user preferences.
Each ApplicationPage is defined by one or more dockable Views placed in different sections of the page area (left, bottom, center, etc). A view is also defined by a singleton ViewDescriptor. View instances may be stacked, tabbed, etc. The same view may be open on different pages in different windows--but only one view instance per view descriptor is allowed per page.
When views are added to a page, either programmatically via the "showView" method or at startup during page layout (ApplicationPageLayoutBuilder hook in the buildInitialLayout() method of PageDescriptor), the page creates a ViewPane which manages the visual presentation of the View. Currently this is realized by a SimpleInternalFrame in the default implementation.
The page also tracks and notifies on view lifecycle events: creation, focus gained, focus lost, destruction. This is how a view is notified of activation, for example, so it can register global command executors. The page caches view instances, and informs the views when they are activated/deactivated/disposed.