Quicksilver + Eclipse = QSEclipse

This is an off topic post as it has nothing to do with Data Binding so I'll keep it short...

In my spare spare time I've been hacking on a Quicksilver plugin to make it aware of Eclipse workspaces. If you're into Quicksilver and would like to learn more about the plugin head on over to the qseclipse project on Google Code. I consider it alpha but it works. Direct any feedback to the qseclipse Google group.

BeansObservables and registering for PropertyChangeEvents

In the past we've been a bit inconsistent about how BeansObservables registered for PropertyChangeEvents. In some cases we'd look for the addPropertyChangeListener(...) method that accepted the name of the property and in others cases we didn't. In order to ensure that your bean worked in all scenarios you had to implement both. As of this weekend we now abide by the bean spec (see section 7.4.1 and 7.4.5) in all cases. We look for the optional, with name, version first but fall back to the unnamed version if it is not found. Also if neither is found a warning is logged with the intention of making issues easier to debug.

EclipseCon Data Binding BoF

There's a BoF proposal for Data Binding at EclipseCon. If you'd like to attend head on over and comment so that we can know how many to expect. Hope to see you there.

Upgrading to JFace Data Binding 3.3M5 Gotcha

There shouldn't be many API changes in Eclipse 3.3M5 that won't be obvious when you upgrade (just look for the red Xs). But there was a change in the number and sometimes order of parameters in the WritableValue, WritableSet, and WritableList constructors. If you're using any of these classes it would be wise to do a quick search to ensure that what you're passing is what we're expecting. The parameters to the constructors are untyped so the compiler won't be able to catch all of these changes.

At the moment we only have one API change planned that we feel still needs to happen before we hit 1.0 and it will hopefully occur in the beginning of M6 development. We're getting close to 1.0 so if you have any issues/complaints/thorns in your side, any at all, please let us know. We take a lot of pride in this and want to make sure that we're starting off on the right foot.

Data Binding Validation Story

In preparation for the 1.0 release the validation story has changed. Previously for a target observable value change the pipeline was:

1. BindingEvent.PIPELINE_AFTER_GET - retrieve target value


2. BindingEvent.PIPELINE_AFTER_VALIDATE - validate target value


3. BindingEvent.PIPELINE_AFTER_CONVERT - convert target value to model type


4. BindingEvent.PIPELINE_AFTER_BUSINESS_VALIDATE - validate converted value


5. BindingEvent.PIPELINE_AFTER_CHANGE - set converted value on model

Validation occurred during PIPELINE_AFTER_VALIDATE and PIPELINE_AFTER_BUSINESS_VALIDATE.

The pipeline for value bindings has become:

1. BindingEvent.PIPELINE_AFTER_GET - retrieve target value


2. BindingEvent.PIPELINE_AFTER_CONVERT - convert target value


3. BindingEvent.PIPELINE_BEFORE_CHANGE - a placeholder for expensive validation


4. BindingEvent.PIPELINE_AFTER_CHANGE - set on model

Validators can now be registered for any position, multiples can be registered for a single position, and validation can occur on model to target changes as well as target to model.

Policies

Policies are the way to define when the model is to be updated. The currently supported policies are BindSpec.POLICY_AUTOMATIC and BindSpec.POLICY_EXPLICIT. A common need in dialogs is the ability to defer updating of a model until the user selects OK/Apply. Previously in order to accomplish this you had to create a temporary model to bind to the UI so that it wouldn't update the live model. Now you can specify BindSpec.POLICY_EXPLICIT for the update policy via the BindSpec and control when the model is updated. You can also specify the target validation policy so that the target is validated on change but the model is not updated until you invoke an explicit update.

There aren't any snippets of the functionality yet but hopefully I'll be able to create one soon. I just wanted to give a heads up for anyone using HEAD as there are some nonpassive changes in this.

Master Detail - Distilling the Pattern

Yesterday I went over master detail in the context of list selection. In the list selection post there were 3 steps that were required to setup the list selection master detail. But the guts of master detail were really just the first two, the third was to setup the viewing of the detail.

1. Observe changes of the viewer's selection.


2. Observe the name property of the selection.


3. Bind the text of the Text widget to the name detail (selected person's name).

In the 2 steps we're concerned with we have 3 players:

1. viewer - maintains a reference to the selection and provides change events when it changes


2. selection (person)- maintains a reference to the name and provides change events when it changes


3. name - value to display

If using dot notation we'd be able to access the value of the detail with something like the following (assuming the selection is not null)...
viewer.selection.name

If we genericize the roles a bit we get...
container.master.detail

The Pattern

The master detail APIs will satisfy your use case if...

1. you need to observe container.master.detail


2. AND the master instance can be replaced over time

Non Selection Use Case

A use case that arose recently on the newsgroup was how to setup the binding to a Person model that can be replaced over time. This was in the context of implementing presentation model. The following code was being used as the presentation model.

class ViewModel {
 private Person person;
 
 public void getPerson() {
  return person;
 }
 
 public void setPerson(Person person) {
  this.person = person;
 }
}

Over time a new person would be set and the UI had to update. Expressed in dot notation this was viewModel.person.name. The only change that needed to occur to the code was that ViewModel needed to fire change events for Person and then the binding was wired up like normal.

class ViewModel {
 private Person person;
 private PropertyChangeSupport changeSupport = new PropertyChangeSupport(this);
 
 public void addPropertyChangeListener(String propertyName, PropertyChangeListener listener) {
  changeSupport.addPropertyChangeListener(propertyName, listener);
 }

 public Person getPerson() {
  return person;
 }

 public void setPerson(Person person) {
  changeSupport.firePropertyChange("person", this.person, this.person = person);
 }
}

// Create an observable to observe changes in the view model
IObservableValue personValue = BeansObservables.observeValue(
  viewModel, "person");

//Bind to the name detail of the current person
dbc.bindValue(SWTObservables.observeText(form.getTextName(),
  SWT.Modify), BeansObservables.observeDetailValue(Realm
  .getDefault(), personValue, "name",
  String.class), null);

WritableValue, for those looking for a shortcut

If you're in a position where it doesn't matter if your model is a java bean, look into one of my favorite classes WritableValue. Your code then becomes...

class ViewModel {
 /**
  * observable value to maintain the person instance
  */
 private IObservableValue personObservable = new WritableValue(Person.class);
 
 public IObservableValue getPersonObservable() {
  return personObservable;
 }
}

//Observe the detail.
IObservableValue detailObservable = BeansObservables
    .observeDetailValue(Realm.getDefault(), viewModel.getPersonObservable(), "name",
        String.class);

Code to set the person would be...

viewModel.getPersonObservable().setValue(person);

Asking JFace Data Binding questions

Today was the data binding webinar and from what I can tell it went well. There were quite a few questions and I think most if not all got answered. But if you attended or not and have any questions about data binding feel free to ask them on the eclipse.platform newsgroup. You should always be able to find the latest information on how to get in contact with us on the FAQ.

Also in the evenings and on weekends I try to be on IRC on #eclipse and #eclipse-dev. I'm bradleyjames. Feel free to stop by and say hello.