Andrew Pietsch's Weblog

One of the key goals for my binding infrastructure has been to make it easy to extend the value models to suit your business requirements. The idea was let you define a custom value model properties and have the library automatically manage them. I had this working pretty well, but it was pretty painful to set up, and definitely not something I’d wish on others.

Enter Mixins. Somewhere along the line it occurred to me that I could create Mixins that provide standard ValueModel extensions and their handlers out of the box. The first test was to convert my ComponentValueModel interfaces that defines standard component properties such as enabled, editable and visible.

public interface ComponentValueModel extends ValueModel
{
    @DefaultValue(true)
    public boolean isEnabled();
    public void setEnabled(boolean enabled);

    @DefaultValue(true)
    public boolean isEditable();
    public void setEditable(boolean editable);

    @DefaultValue(true)
    public boolean isVisible();
    public void setVisible(boolean visible);
}

Using this mixin is now as simple as..

// install the mixin that defines the ComponentValueModel
// interface and standard handlers.
Pectin.registerMixin(ComponentMixin.instance());

// create a presentation model that vends ComponentValueModels
pm = new BeanPresentationModel<Person, ComponentValueModel>(...);

// all the value models returned by the presentation model will
// implement the mixin interface.
ComponentValueModel cvm = pm.get("firstName");

// changes to the mixin properties will be automatically handled
// by the mixin
cvm.setEnabled(true);
cvm.setEditable(false);
cvm.setVisible(true);

From here the mixin is responsible for updating the state of components bound to ComponentValueModels. The mixin uses styles that map particular model properties to particular components allowing you to control the way particular properties effect particular components.

So far I’m really pleased with the progress.

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.

1. Must be able to extend the ValueModel interface with real meta data methods.
2. Must be able to modify the behaviour of the component bindings to use use the custom ValueModel metadata defined above.
3. Must support buffering natively.
4. 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:

1. Obfuscated - some fields need to be be obfuscated from view (such as credit card numbers) based on the users profile.
2. These fields also needed the ability to be un-obfuscated temporarily.
3. 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.
4. Enabled - Fields that were editable could be either enabled or disabled.
5. 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.