private static List list1 = Arrays.asList("a", "b", "c");
private static List list2 = Arrays.asList("a", "c", "d");
 
// Diff of list1 vs list2:
//  removed 'b' at 1
//  added 'd' at 2

With a little help from the class Diffs (found in the org.eclipse.core.databinding.observable bundle / package), it only takes a few lines, as shown in the snippet below. Thank you, Eclipse Databinding!

If you don’t see the snippet click here.

If you take a look at the RAP Demos page you’ll find the e4 contacts demo running on RAP. If you want to try it out yourself or even help to contribute to this effort, take a look this wiki page. In case you’re interested what you can do with e4, be sure to participate in the e4 webinars.This week, there will be Part 2 with topics like RAP, the Compatibility layer and the flexible resources model. Looking at the questions that came up in the last RAP webinar and the first part of the E4 webinar, people seem to be very interested how e4 and RAP play together. I’ll try to answer the open questions during the webinar this week. Looking forward to a great event.

As we can see on the screenshot above, the status message informs us of a violated validation constrain. So, how is such  kind of crosscutting validation achieved? First of we need some kind of model, to hold the start and end value. Next we need the two DateTime widgets and the corresponding DateTimeObservableValue. The observables can than be tied to the bean model, holding the start and end values. In order to create a crosscutting validation for the dates, we introduce a custom PeriodValidator extending a MultiValidator, which is in fact an implementation of a ValidationStatusProvider.The MultiValidator lets us implement a validate() method, returning an IStatus corresponding to our validation results. Since we are implicitly implementing a ValidationStatusProvider, the state of our validation can be bound to any party interested in the validation result. Here is the implementation of the PeriodValidator, comparing the start and end date (ignore the shortcomings of the Date class):

public class PeriodValidator extends MultiValidator {

private final IObservableValue start;
private final IObservableValue end;

public PeriodValidator(final IObservableValue start, final IObservableValue end) {
this.start = start;
this.end = end;
}

@Override
protected IStatus validate() {
Date startDate = (Date) this.start.getValue();
Date endDate = (Date) this.end.getValue();
IStatus status = ValidationStatus.ok();

if ((this.start != null) && (this.end != null)) {
     if (startDate.after(endDate)) {
          status = ValidationStatus.error(”The start date has to be before the end date.”);
     }
}
return status;
}
}

As we can see, there is not much magic going on in the PeriodValidator. Lets have a look at the broader context, in which this MultiValidator is applied. The following code demonstrates the overall setup of the databinding. Note how the validation status (wrapped in an IObservableValue) is obtained from the PeriodValidator and bound to the status Text widget.

private void createDatabinding() {

DateTimeObservableValue startObservable = new DateTimeObservableValue(this.dateTimeStart);
DateTimeObservableValue endObservable = new DateTimeObservableValue(this.dateTimeEnd);
DataBindingContext context = new DataBindingContext();

// bind start and end
UpdateValueStrategy modelToTarget = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
UpdateValueStrategy targetToModel = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     startObservable,
     BeansObservables.observeValue(this.period,Period.PROP_START), targetToModel, modelToTarget);

context.bindValue(endObservable,
     BeansObservables.observeValue(this.period, Period.PROP_END), targetToModel, modelToTarget);

// bind status
PeriodValidator periodValidator = new PeriodValidator(startObservable, endObservable);
modelToTarget = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
modelToTarget.setConverter(new Converter(IStatus.class, String.class) {

public Object convert(final Object arg) {

if (arg instanceof IStatus) {
     IStatus status = (IStatus) arg;
     return status.getMessage();
}

return null;
}
});

targetToModel = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     SWTObservables.observeText(this.status),
     periodValidator.getValidationStatus(), targetToModel, modelToTarget);
}

The validation status of the period validator is updated everytime any of the DateTime widgets is changed. In turn the validation message is updated to reflect the validation state.

You can download the the entire project containing the sample snippets here.

Also note that you will need to adjust the elements on the classpath. See the .project file for the required libs.

I hope you found these hints valuable and am looking forward to your comments and suggestions.

The DateTime widget represents one value: a java.util.Date. This Date object is the one we want to get and set on the target (target being the UI widget). Therefore we wrap the DateTime in an IObservableValue by extending the AbstractObservableValue class. Essentially an IObservable* offers methods to get and set data, to determine the type of data and to register listeners to be notified of changes. The following code demonstrates a skeleton implementation of an IObservableValue.

public class DateTimeObservableValue extends AbstractObservableValue {

  private final DateTime dateTime;
  Listener listener = new Listener() { ... };

  public DateTimeObservableValue(final DateTime dateTime) {
    this.dateTime = dateTime;
    this.dateTime.addSelectionListener(this.listener);
  }

  @Override
  protected Object doGetValue() {
    // the utility method creates a Date from the DateTime
    return dateTimeToDate();
  }

  @Override
    protected void doSetValue(final Object value) {
      if (value instanceof Date) {
        // the utility method sets the date on the DateTime
        dateToDateTime((Date) value);
      }
  }

  @Override
    public Object getValueType() {
    return Date.class;
  }

  @Override
    public synchronized void dispose() {
    this.dateTime.removeSelectionListener(this.listener);
    super.dispose();
  }
}

The implementation details are not very special. The getValueType() method has to return the type represented by this IObservableValue (which is the type Date). The do methods set and get the Date value. Since the observable has to propagate changes in the DateTime widget as soon as they ocurre, we attach a listener on the DateTime widget to inform any registered IValueChangeListener of the event. The listener implementation looks like the following:

Listener listener = new Listener() {

  @Override
  public void handleEvent(final Event event) {
    Date newValue = dateTimeToDate();

    if (!newValue.equals(DateTimeObservableValue.this.oldValue)) {
      fireValueChange(Diffs.createValueDiff(DateTimeObservableValue.this.oldValue, newValue));
      DateTimeObservableValue.this.oldValue = newValue;
    }
  }
};

In the DateTime listener we inform any interested IValueChangeListener of our DateTimeObservableValue. In order to avoid unnecessary propagation of update events in the databinding context, we compare the last set Date in the IObservableValue with the new value. Next we create a ValueDiff from our new date value and fire the the value change event. The advantage of listening to the changes in the DateTime widget, is that we are able to fire events which are either invoked by the user changing the DateTime widget or by programmatic changes of the IObservableValues wrapped Date.

You can download the full listing of the observable class here: DateTimeObservableValue.zip

As we can see, it is quite easy to write a custom observable for any kind of widget or datastructure, represented by a single value…  So, how do you embed your data in custom observables? Any obstacles you had to overcome? Problems you faced? Share them with us.