Summary
A new JSR aims to define a standard application framework for rich-client and desktop Java applications. JSR 296 "will define infrastructure common to most desktop applications. In so doing, Swing applications will be easier to create."
Advertisement
While various application frameworks have for long aided the construction of server-side applications, client-side Java apps have not benefited from similar, high-level building blocks.
The API of Java's native UI toolkit, Swing, for instance, defines components and their interactions, but not how to start and stop a desktop application, how to populate Swing UI widgets with data, how to validate data entered in the UI, how to authenticate a user, or how to structure a multi-panel input form, just to mention a few decisions Swing developers must make. The lack of such high-level constructs have made building Swing applications harder, and resulted in poorly-coded (and poorly performing) Swing applications.
At least three desktop Java application frameworks emerged in the last few years: NetBeans RCP, Eclipse RCP, and Spring RCP. Each framework attempts to provide an infrastructure for building Java desktop apps, yet each approaches the problem differently. The recently accepted JSR 296, "Swing Application Framework," may finally unify the best practices learned from these frameworks, although, as the JSR's title states, the solution will be specific to Swing:
Well-written Swing applications tend to have the same core elements for startup and shutdown, and for managing resources, actions, and session state. New applications create all of these core elements from scratch. Java SE does not provide any support for structuring applications, and this often leaves new developers feeling a bit adrift, particularly when they're contemplating building an application whose scale goes well beyond the examples provided in the SE documentation.
This specification will (finally) fill that void by defining the basic structure of a Swing application. It will define a small set of extensible classes or "framework" that define infrastructure that's common to most desktop applications:
The essential application lifecyle, startup and shutdown, with well defined milestones so that applications can insert startup or shutdown work when the application has reached a well known state.
Support for loading localized resources. Desktop applications deal with a set of common resource types beyond message strings, notably images, colors, and fonts. Resources can also be specific to the platform or to the application's "branding".
Persistent session state. Most applications need a way to persist things like top level window geometry across sessions. Automatic support for such common cases as well as for loading and storing arbitrary session data at startup and shutdown time, would be useful in most Swing applications.
Actions define the behavior of Swing application from the user's perspective. In all but the smallest applications, it's useful to be able to loosely couple an Action's (localized, branded, etc) presentation from its implementation. Action implementations often must perform some work asychronously [and interact with] the Swing event dispatching thread. The application framework would provide support for doing so and for providing GUI feedback while significant work is being done on the user's behalf.
What other common desktop functionality do you think this framework should include? And to what extent do you think such a framework will encourage developers to build more rich-client Swing applications?
Maybe it would be useful to be able to automatically make a UI out of a program's data and functions using reflection/introspection; i.e. by declaring the program's data models and commands.
For example, one could declare a data model 'list of Foo' and commands 'insert/delete/delete all/sort' and get the respective UI automatically: a Foo editing form, a list view object, a context menu in the list view with the commands, a toolbar with the commands, etc.
I was the lead developer of a big swing ui for a erp software product. Our ui was made up of a framework not unlike this proposal and two application parts. We considered using eclipse rcp but it was not ripe enough (the same with netbeans rcp) and spring rcp didnt exist back then. (the project started beginnig of 2004).
One major demand to the framework was the need for a LnF and the customability of ui components. I think this is a major demand not only for the company I worked with, because branding of apps to the ci is an important part of good software. The same applies to usability which is achieved through an sophisticated interaction between components on the ui. These two things can be achieved with swing in a really good way.
I think any good framework has to keep those points in mind. Not only thinks like startup shutdown behaviour, resource management and a good incorporated service and plugin concept.
Eclipse RCP has many great solutions to the latter points I mentioned but lacks in the field of LnF and component customization. Netbeans RCP is in my opinion way to complex and not documented enough. For Spring RCP I cannot tell...
My hope for a good swing framework would be to combine the beauty of the underlying system of eclipse with the beauty and power of swing. I know that swing is complex and hard to learn, but so are all potent frameworks. I can savly say, that there is no task I encountered, that I could not solve in swing, ever. This is the usp of swing and it should be kept high.
> Maybe it would be useful to be able to automatically make > a UI out of a program's data and functions using > reflection/introspection; i.e. by declaring the program's > data models and commands. > > For example, one could declare a data model 'list of Foo' > and commands 'insert/delete/delete all/sort' and get the > respective UI automatically: a Foo editing form, a list > view object, a context menu in the list view with the > commands, a toolbar with the commands, etc.
That sounds to me a bit like Rails. I think such a functionality goes beyond the scope of such a JSR, which is to provide a common framework for constructing Swing apps, not a method to generate data access apps in Swing.
I think the goal you're describing is a good one, though. But instead of implementing it at the level of a framework, it could be implemented as a tool that interacts with a set of high-level Swing components. For instance, the master-detail view pattern is very common in all data-editing UIs, and that might be a good starting point for what your describe.
> That sounds to me a bit like Rails. I think such a > functionality goes beyond the scope of such a JSR, which > is to provide a common framework for constructing Swing > apps, not a method to generate data access apps in Swing. > > > I think the goal you're describing is a good one, though. > But instead of implementing it at the level of a > framework, it could be implemented as a tool that > interacts with a set of high-level Swing components. For > instance, the master-detail view pattern is very common in > all data-editing UIs, and that might be a good starting > point for what your describe.
Yeap, it's a step beyond this JSR, although directly related. Maybe in a future JSR somebody will think about it. I would prefer to have it as a framework though, so I can change my program with an editor and then compile my program and have the changes ready. It would be cool to be able to generate the UI from the program (it will save many work hours).
Here are a few items, that really should be standalone (i.e. not need the whole rest of the framework). This list is loosely based on what I've needed to implement, sometimes more than once:
* auto-propagation of component actions to menus (e.g. the edit menu or context-sensitive submenus) * auto-spawning of long-running actions from the EDT, while handling the results elegantly (I've posted some thoughts at http://rabbit-hole.blogspot.com/2006/05/of-swing-frameworks-and-threaded.html) * common components: preference editors, about box, splash screen, a few application frame variations (even a default "browser", which can look at any "destination" and keeps track of a history + bookmarks, navigate and/or cancel a navigation) * application status propagation; propagate status from arbitrary threads up to the top-level application UI. * automatic conversion of resources into Actions, for example:
action.name=&Cut action.icon=scissors.png action.mnemonic=C action.desc=Perform a cut operation
* save/restore application visual state: windows, split panes, tree expansion state * augmented resource loading, e.g. getIcon(key), getString(key), getString(fmtKey, arg1, arg2, ...) * management of primary and auxiliary windows (actions of which might appear in a "windows" menu)
How about data binding? In particular binding Java bean properties to Swing components. I know this can be a separate framework (such as with JGoodies), but I tend to spend much time implementing PropertyChangeListeners on my GUI panels to keep all fields in synch. This is especially important when you have more than one view on the same bean. It also gets more messy when you mix in validation and vetoable property changes.
Would be great if you could specify a bound java bean property as the data model for a swing component.
Anyways, I suggest binding be added to that list. I believe Spring RCP includes it.
A keyboard shortcuts editor. A gui control that the end user would use to change keyboard shortcuts. Many applications don't even have keyboard shortcuts, and of those that do, most don't allow changing the shortcuts. Of the applications I've seen that do, all have rolled their own interface, with varying degress of success and usability. IntelliJ is probably the best example I've seen, jEdit is another good one. OpenOffice has a confusing dialog. Some other programs I've seen do a very poor job of this.
A docking framework. Allow arbitrary Panels to be docked on the north, south, east, west or centre panels. Support user drag and drop of Panels between the different locations. Support automatic placing of Panels on different Tabs if there is more than one Panel on one docking location. Again, IntelliJ provides a great example.
A central event bus. Support registering and deregistering of listeners onto a central event bus. Support posting of events to that event bus.
A "Tip of the Day" dialog box.
All these can be implemented yourself, but standard implementations would save a lot of time and hassle.
Previous Topic
