GUI Commands 2.1 is now available. This release has a few new features, API updates and bug fixes. Please refer to the change notes for a complete list of changes.
This release is a free upgrade from 2.0.
New Features
- New annotions for creating and binding ActionCommands and SwingWorkerCommands from regular methods. The new annotations are processed using GuiCommands.bindAnnotatedCommands(..).
- New DEBUG mode for command groups that shows missing members. The debug mode is activated by specifying the system property `com.pietschy.command.debugGroups=true`.
- New support for DelegatingToggleCommands and DelegatingToggleGroups.
- New converter utility for converting old 1.1.x configuration files to the new 2.x format.
Improvements
- Improved and updated documentation, particularly the sections on binding, delegates and expansion points.
- Various API Improvements and cleanups detailed in the change notes
You can download the new release from the GUI Commands Website
In light of my previous post, I’ve long pondered how I could create a generic PresentationModel/ValueModel framework that can be customised on a per project basis.
- Must be able to extend the ValueModel interface with real meta data methods.
- Must be able to modify the behaviour of the component bindings to use use the custom ValueModel metadata defined above.
- Must support buffering natively.
- Must be easy to use out of the box and easy to customise.
I’d had a couple of goes at this in the past but yesterday I had a bit of a moment where I believed it might be possible (either rightly or wrongly).
Ignoring any doubts I tried a few ideas and to my surprise it progressed pretty well. I think this was partly because I’d been spending more time away from the Mac where my brain could think in peace.
Anyway, I shall continue plugging away and see how it turns out.
I recently worked on a large scale Swing project where we made heavy use of value models in the UI. The requirements were complex as the interface designers were more interested in what was good rather than what was easy.
In our technology selection we examined various value model frameworks such as Spring Rich Client, JGoodies Binding and PGS Binding. Of all the frameworks we examined, none provided a simple mechanism for adding meta data to our value models.
Some of our meta data included the following properties:
- Obfuscated - some fields need to be be obfuscated from view (such as credit card numbers) based on the users profile.
- These fields also needed the ability to be un-obfuscated temporarily.
- Editable - Some fields needed to be displayed, but were only editable if the user had the required privileges. Non editable fields looked like labels and not like regular components.
- Enabled - Fields that were editable could be either enabled or disabled.
- Visible - Fields and forms needed to be shown and hidden.
Even if we could find a framework that could model these aspects it would be unlikely that it would match the exact look and feel requirements of our designers. So in the end, we decided to write our own.
Our approach was to use the ValueModel as both and Adapter and Decorator. As an adapter the value model was responsible for transfering the value to and from the source. As a decorator it provided additional information about the value that was relevant for the UI.
The key to the design was that the infrastructure modeled our business requirements. In the end developers had very little code to write to create a whole dollar, obfuscated `JFormattedTextField`, and none of it was difficult or Swing-ish.