GUI Hierarchy - Spring Rich Client Project (Spring Rich)

The Spring Rich Framework introduces a series of GUI components that assemble the developer's application. Out of the box, the developer need only supply the code necessary to build a page view. But what is a page view, and what else does Spring Rich do for me and not do for me?

The GUI Layers

Out of the box, Spring Rich introduces a couple abstractions regarding the application's main frame (ApplicationWindow) and a child component of the frame called ApplicationPage. Now neither of these beans are GUI components in their own right, but they do contain the code necessary to create and initialize GUI components. They also contain handlers for some common GUI functionality like the application close. At some point in the initialization process, they will even invoke a bean that describes the GUI component that the developer wants to get on the screen.

Let's take a visual peek at the stock Spring Rich GUI structure.

ApplicationWindow

The standard Spring Rich implementation of org.springframework.richclient.application.ApplicationWindow is org.springframework.richclient.application.support.DefaultApplicationWindow. During the launch of the application (by means of org.springframework.richclient.application.ApplicationLauncher), the ApplicationWindow's createNewWindowControl method will fire resulting in the creation of a javax.swing.JFrame.

This JFrame may eventually be styled with a menubar, toolbar and statusbar. Since this is a framework, the creation of these components is not directly in the hands of the developer. The developer need only provide Spring Rich with command implementations, and the framework will automatically create the GUI components.

If the developer wishes to provide an alternative to JToolBar (say JCoolBar) she may subclass the DefaultApplicationWindow class and supply an alternative component to the createToolBarControl method.

Design Consideration

I have not delved into Spring Rich's concept of CommandGroups at this time. There may be a more appropriate mechanism to supply alternative implementations of JToolBar or JMenuBar than subclassing DefaultApplicationWindow.

It is interesting to note, that even if the developer indicates that she does not want a toolbar or statusbar as part of her application, they get created anyway. They are even added to the JFrame's layout, however they are not made visible.

ApplicationPage

The standard implementation of the org.springframework.richclient.application.ApplicationPage is org.springframework.richclient.application.support.DefaultApplicationPage. Many of us, when developing a Swing application would have no need for this additional component, but it provides a couple important services in the Spring Rich framework.

Firstly, ApplicationPage is responsible for creating the developers content component. This is the stuff that you want to get up on the screen.
One would expect that the framework will mature, at some point, to support multiple PageDescriptors per ApplicationPage. If this happens, ApplicationPage would probable assume the role of controller for these multiple views.

Currently, the ApplicationPage creates a container called SimpleInternalFrame. This result of this JPanel subclass is added to the content region of the parent JFrame. A colleague had recently been irked by the fact that this pane displayed a title bar with an icon at the top. Indeed, I agree that it is odd to have this title bar present for most applications.

One approach to removing the title bar appears to require the developer to subclass DefaultApplicationPage and provide an alternative implementation of createPageComponent, however the SimpleInternalFrame is not instantiated in this class. Another class named org.springframework.richclient.application.PageComponentPane must be tinkered with instead.

An alternative approach involves a patch to SimpleInternalFrame itself. The panel obtains the icon and title text for the title bar from the developer's PageDescriptor. If the developer were to provide no icon or title, then perhaps the SimpleInternalFrame could be coaxed to display nothing. This may be a naïve solution to the problem, because the PageDescriptor's icon and title may have another very useful purpose, however it seems to do the trick without any side-effects. There is a JIRA posting that contains some more detail.

PageDescriptor

To do