fireChangeEvent()

A new direction for bindings?

2010-09-02T00:28:00.007-06:00

I'm happy to report that I've been given company approval to port the relevant components of our Flex data binding library back to Eclipse Data Binding.

I haven't started the actual port yet--there are still some concepts on the Flex side that are not a perfect match to Java and existing idioms in Eclipse Data Binding. You'll see what I mean.

To avoid conflating the port to Java with the general API I'm going to just present what the Flex API looks like.

  Bind.from(source, "foo")
      .to(target, "bar");

This binding watches the source.foo property, and writes the new value to target.bar each time a change it detected. Now add some validation and conversion magic:

  Bind.from(source, "foo")
      .validate(Validators.stringToNumber)
      .convert(Converters.stringToNumber)
      .validate(Validators.greaterEqual(0))
      .validate(Validators.lessThan(10))
      .to(target, "bar");

Here we've added several additional steps in the pipeline.

After source.foo changes, we first validate that the string can be converted to a number. If so the pipeline continues to the next step, and terminates otherwise.
Next we convert the string to a number
Now validate that the number is greater than or equal to zero. If so the pipeline continues to the next step, and terminates otherwise.
Now validate that the number is less than 10. If so the pipeline continues and the number, now verified to be in the range [0,10), is written to target.bar.

Now suppose our binding is misbehaving somehow, and we want to troubleshoot. We can add logging steps to the pipeline in between the other steps so we can see exactly what is going on:

  Bind.from(source, "foo")
      .log(LogEventLeven.INFO, "source.foo == {0}")
      .log(LogEventLeven.INFO, "validate {0} is a number")
      .validate(Validators.stringToNumber)
      .log(LogEventLeven.INFO, "convert {0} to a number")
      .convert(Converters.stringToNumber)
      .log(LogEventLeven.INFO, "validate {0} >= 0")
      .validate(Validators.greaterEqual(0))
      .log(LogEventLeven.INFO, "validate {0} <>
      .validate(Validators.lessThan(10))
      .log(LogEventLeven.INFO, "set target.bar = {0}")
      .to(target, "bar");

(In Flex, string formatting is done with {n} format instead of the %s syntax which Java inherited from C. The log statement passes the values in the pipeline as additional arguments which you can reference in log statements.)

These log steps are a real lifesaver for tracking down and squashing bugs in your binding code.

If you've already worked with Eclipse Data Binding you may have noticed something else: you are no longer constrained to the standard data-binding pipeline. You are free to add steps in the pipeline wherever you like and in any order you like.

Next up is two-way bindings. The bind class provides a twoWay method which connects two bindings to the other one's starting point:

  Bind.twoWay(
      Bind.from(source, "foo"),
      Bind.from(target, "bar") );

is equivalent to:

  var lock:Lock = new Lock();
  Bind.from(source, "foo")
      .lock(lock)
      .to(target, "bar");
  Bind.from(target, "bar")
      .lock(lock)
      .to(target, "foo");

Notice that each binding has a "lock" step in the pipeline. Only one binding can hold a lock at a time. This solves the common infinite loop problem:

source.foo changes. binding one executes, writing the value to target.bar
target.bar changes. binding two executes, writing the value to source.foo
source.foo changes. binding one executes, writing the value to target.bar
...
stack overflow!

Since only one binding can hold the lock at a time, this is what happens instead:

source.foo changes. binding one acquires the lock and executes, writing the value to target.bar
target.bar changes. binding two attempts to acquire the lock but it is already acquired. binding two aborts.
binding one releases the lock

You should never add the same lock more than once to a single binding, since that would guarantee that the binding will never run.

Two-way bindings can use validations, conversions, logging, locks etc just like regular one-way bindings (since two-way bindings are just two one-way bindings wired up to eachother):

  Bind.twoWay(
      Bind.from(person, "birthDate")
          .convert(Converters.dateToString(dateFormat))
      Bind.from(heightText, "text")
          .validate(Validators.stringToDate(dateFormat))
          .convert(Converters.stringToDate(dateFormat))
          .validate(Validators.lessEqual(now))
      );

We usually leave out the validations in the model-to-UI bindings. It's usually only important to apply validations when you're copying data back from the UI to the model, to make sure domain constraints are satisfied, such as ensuring that a birth date occurred in the past.

And now for my favorite part: binding from multiple sources, to multiple destinations. Raise your hand if you have ever had to wire up a UI form like this:

  Is there a foo? (o) Yes  ( ) No <-- fooRadioGroup

  Enter bar: ____________________ <-- barText

Requirements:

fooRadioGroup.selectedItem is bound to model.foo (a boolean)
barText.text is bound to model.bar (a string)
barText must be enabled iff fooRadioGroup selection is Yes.
When the user clicks "No," set model.bar to null but do not clear the text box. If the user clicks "Yes" again, set model.bar back to the contents of barText

Requirements 1 and 3 are easy:

  var fooLock:Lock = new Lock();
  Bind.twoWay(
      Bind.from(model, "foo"),
      Bind.from(fooRadioGroup, "selectedItem"),
      fooLock); // explicitly provide the lock, see more below

  Bind.from(fooRadioGroup, "selectedItem")
      .to(barText, "enabled");

Requirements 2 and 4 are kind of related to eachother. The model-to-UI binding is simple enough: just write the value straight across:

  var barLock:Lock = new Lock();
  Bind.from(model, "bar")
      .lock(barLock)
      .to(barText, "text");

However the inverse binding (UI-to-model) must also take fooRadioGroup.selectedItem into account to decide whether to write back barText.text (if Yes is selected) or null (if No is selected).

The Bind class has another trick up its sleeve:

  Bind.fromAll(

      Bind.from(fooRadioGroup, "selectedItem")
          .lock(fooLock),

      Bind.from(barText, "text")

      )
      .lock(barLock)
      .convert(function(foo:Boolean, bar:String):String {
        return foo ? bar : null;
      })
      .to(model, "bar");

Look closely. The binding pipelines that we pass to fromAll(...) become the arguments, in the order they are provided, to the converter and validator functions further down the pipeline. The first pipeline is from fooRadioGroup.selectedItem and therefore that boolean value is the first argument to the converter. Likewise, the barText.text pipeline is provided second, so that string value becomes the second argument to the converter.

The converter takes multiple values but returns only a single value. This is where those values get coalesced into a single value that we can write to the model--in this case, a String value or null.

The outer pipeline adds a locking step on barLock, which is expected since we need to prevent infinite loops between the last two pipelines. However we are also locking on fooLock, on the first of the inner pipelines. We had a problem with our bindings overwriting values in the UI depending on the order things were initialized.

It turned out that without that lock, if a new model object was set, then the foo binding would fire first. Thus model.foo was copied to fooRadioGroup.selectedItem. But that would trigger our last binding to execute, so if the new foo value was false, then the last binding would override anything in the text box and set null on the model.bar field, before the model.bar => barText.text binding had a chance to execute!

A good rule of thumb is that any time you need to bind from multiple sources, you should make sure to create a lock to share between all the bindings to relate to the same field in the model.

Obviously there are several concepts that will have to be adapted to work elegantly with our existing APIs. Realms are a missing piece (Flex is single-threaded so we didn't even have to consider it). Also we would want to try to retrofit the existing binding classes to use this new API transparently, like we did with the transition from custom observables to custom properties.

So there you have it. This is my current vision of what Eclipse Data Binding should evolve toward.

Comments?

Back in the Saddle

2010-08-11T23:38:00.002-06:00

I've been away (and neglecting Eclipse DataBinding) for a long time now. I want to offer my sincere apologies to any and all who've been affected by my lack of attention.

Now that I've settled back into my old routine, I have a new problem. There is a mountain of new / updated bugs in Bugzilla and not enough free time to catch up on all of them. Please help me prioritize by pinging the tasks important to you! Vote, comment, post patches, whatever you have time for--just let me know where the pain points are.

About the time I disappeared from Eclipse, I started a new job at Overstock.com and it's really an awesome place to work. We're always looking to hire new programmers, so send me a line if you're looking for something new.

While at Overstock I've been doing some Flex development, and (surprise!) working on a data binding library in Flex. Yes, technically Flex already has declarative data binding baked in. What I'm working on brings data binding to the ActionScript side, and gives you full support over the binding pipeline: conversions, validations (sound familiar?), synchronized access, one- and two-way bindings, bindings from multiple sources and coalescing the values together. It's really cool.

This work in Flex has been a golden opportunity to make a fresh start and use the lessons learned from Eclipse DataBinding. Pending company approval I hope to port all that goodness back to Java sometime soon. Stay tuned.

Disclaimer: Opinions are my own and do not reflect or represent my employer.

Bind a viewer in one statement with ViewerSupport

2009-02-12T09:27:00.015-07:00

We've added the ViewerSupport class to simplify setting up viewers (including tree viewers), usually in just one statement.

Before:


ObservableListContentProvider contentProvider =
    new ObservableListContentProvider();
viewer.setContentProvider( contentProvider );
viewer.setLabelProvider(
    new ObservableMapLabelProvider(
      BeansObservables.observeMaps(
        contentProvider.getKnownElements(),
        new String[] {
          "title", "releaseDate", "director", "writer" } ) ) );
viewer.setInput(BeansObservables.observeList(model, "movies"));

After:


ViewerSupport.bind(
    viewer,
    BeansObservables.observeList(model, "movies"),
    BeanProperties.values(new String[] {
      "title", "releaseDate", "director", "writer" } ) );

Master-detail editing with multiple selection

2009-02-12T00:09:00.030-07:00

A few weeks ago we released DuplexingObservableValue. This class, among other things, helps make possible master-detail editing on a multiple selection:

Because the selected movies have the same director and same writer, those values are displayed in the master-detail fields at the bottom. However, since they have different titles and release dates, those fields use a stand-in "multi value" instead.

Editing the release date field simultaneously changes the release date of all movies in the selection.

Here's the code that was used to hook up the detail fields to the multi-selection of the viewer:

IObservableList selections = ViewerProperties.multipleSelection()
 .observe(viewer);

dbc.bindValue(
 WidgetProperties.text(SWT.Modify).observe(title),
 DuplexingObservableValue.withDefaults(
     BeanProperties.value("title").observeDetail(selections),
     "", "<Multiple titles>"));

dbc.bindValue(
 WidgetProperties.text(SWT.Modify).observe(releaseDate),
 DuplexingObservableValue.withDefaults(
     BeanProperties.value("releaseDate").observeDetail(selections),
     "", "<Multiple dates>"));

dbc.bindValue(
 WidgetProperties.text(SWT.Modify).observe(director),
 DuplexingObservableValue.withDefaults(
     BeanProperties.value("director").observeDetail(selections),
     "", "<Multiple directors>"));

dbc.bindValue(
 WidgetProperties.text(SWT.Modify).observe(writer),
 DuplexingObservableValue.withDefaults(
     BeanProperties.value("writer").observeDetail(selections),
     "", "<Multiple writers>"));

See the full code listing for this snippet here.

Disclaimer: The method DuplexingObservableValue.withDefaults() was added after the 3.5M5 milestone, so in order to use it you need to check out the databinding projects from CVS HEAD, or be using a more recent integration build.

Introducing the Properties API

2009-02-03T15:21:00.029-07:00

Observables are hard to implement. There are a handful of rules, guidelines and corner cases that observables implementors must pay attention to for data binding to work properly. Observables must call ObservableTracker.getterCalled() for things like ComputedValue or MultiValidator to work; observables must ensure that all invocations are made from within the realm; a ChangeEvent must be fired before ValueChangeEvent; the list goes on. To an extent we've been able to isolate these concerns within the framework, but over time I couldn't help noticing that many of our observables followed a template--a lengthy, complicated one.

In June 2008 I stumbled across bug 194734 and I thought Tom was on to something. I started working on a prototype, which we've been evolving and refining for the past six months. I'm very pleased with the result, and if you've tried implementing your own observables before, I think you will be too.

There are four types of properties: IValueProperty, IListProperty, ISetProperty and IMapProperty. Properties serve two main purposes:

They act as convenient, portable observable factories for a particular property.
They act as strategy objects for the observables they create. That is, the observables use the properties to access, modify, and listen to the property source object.

Suppose you want to observe the "name" property of a bean object:


Person person = new Person("Joe");
IValueProperty nameProperty = BeanProperties.value("name");
IObservableValue personName =
  nameProperty.observe(person);

One of the strengths of properties is how easy it is to combine them to observe nested attributes:


IListProperty childrenProperty = BeanProperties.list("children");
IValueProperty nameProperty = BeanProperties.value("name");
IObservableList namesOfChildren =
  childrenProperty.values(nameProperty).observe(person);

or, a shorter version:


IObservableList namesOfChildren = BeanProperties
  .list("children").values("name").observe(person);

Properties are reusable:


IValueProperty selection = WidgetProperties.selection();
IObservableValue buttonSelection = selection.observe(button);
IObservableValue comboSelection = selection.observe(combo);
IObservableValue spinnerSelection = selection.observe(spinner);

But most importantly, they are easy to implement. Let's close with a real-world example:

DataBinding does not come with built-in support for observing the selection of a DateTime widget (see bug 169876 for an explanation why). However a useful use case is to observe the date portion (year+month+day) and set the time of day to midnight.

The following is a complete property implementation for the DateTime#selection property, that you are free to use in your own projects:


public class DateTimeSelectionProperty extends SimpleValueProperty {
  public Object getValueType() {
      return Date.class;
  }

  // One calendar per thread to preserve thread-safety
  private static final ThreadLocal calendar =
      new ThreadLocal() {
          protected Object initialValue() {
              return Calendar.getInstance();
          }
      };

  protected Object doGetValue(Object source) {
      Calendar cal = (Calendar) calendar.get();

      DateTime dateTime = (DateTime) source;
      cal.clear();
      cal.set(dateTime.getYear(), dateTime.getMonth(),
          dateTime.getDay());
      return cal.getTime();
  }

  protected void doSetValue(Object source, Object value) {
      Calendar cal = (Calendar) calendar.get();
      cal.setTime((Date) value);

      DateTime dateTime = (DateTime) source;
      dateTime.setYear(cal.get(Calendar.YEAR));
      dateTime.setMonth(cal.get(Calendar.MONTH));
      dateTime.setDay(cal.get(Calendar.DAY_OF_MONTH));
  }

  public INativePropertyListener adaptListener(
          ISimplePropertyListener listener) {
      return new WidgetListener(listener);
  }

  private class WidgetListener implements INativePropertyListener,
          Listener {
      private final ISimplePropertyListener listener;

      protected WidgetListener(ISimplePropertyListener listener) {
          this.listener = listener;
      }

      public void handleEvent(Event event) {
          listener.handlePropertyChange(
              new SimplePropertyEvent(event.widget,
                  DateTimeSelectionProperty.this, null));
      }
  }

  protected void doAddListener(Object source,
          INativePropertyListener listener) {
      ((DateTime) source).addListener(
          SWT.Selection, (Listener) listener);
  }

  protected void doRemoveListener(Object source,
          INativePropertyListener listener) {
      ((DateTime) source).removeListener(
          SWT.Selection, (Listener) listener);
  }

  public IObservableValue observe(Object source) {
      // For widgets, we want the display realm instead of
      // Realm.getDefault()
      Realm realm = SWTObservables.getRealm(
          ((Widget) source).getDisplay());
      return observe(realm, source);
  }
}

Now we can observe the selection of a DateTime:


IObservableValue selection =
   new DateTimeSelectionProperty().observe(dateTime);

Today we released WidgetValueProperty as public API, but did not make it in time for M5. However in the future (starting in the next integration build), implementing properties for widgets will be much simpler:

Omit the adaptListener, doAddListener, and doRemoveListener methods
Omit the WidgetListener class
Omit the observe() method
Add a no-arg constructor with a call to super(eventType) in the constructor.

In the example the constructor would call "super(SWT.Selection)". As long as the the widget supports untyped listeners, WidgetValueProperty will handle the listener parts for you.

Watch this guy: Angelo Zerr

2009-01-30T13:18:00.007-07:00

A couple of months ago, Angelo Zerr contacted me out of the blue and asked for feedback on a project he had worked on called "DOM Binding". I was pretty busy at that time and put it on my "someday maybe" list, but he kept pinging me about it and even contributed his code in a Bugzilla so I decided to take a look. Even then, I thought "yeah, w3c DOM stuff, what could be more boring".

Until I ran the small demo app he had written.

I was excited and impressed by this demo app and with how little code it implemented bi-directional synchronization between a forms-based UI and data in XML form. Quite a mouthful, I know, but imagine you had to write one of the editors provided by PDE: some random XML file format cooked up by someone else, which is to be presented in a nice form-based UI through which mere mortals can edit the data. At the same time, the editor should allow experts to view and change the XML text itself, such that any changes get reflected in the UI.

I had always assumed that implementing this would be a major pain in the neck - you would probably write a bunch of Java classes that would be the in-memory representation of the XML data, call the verbose w3c DOM API to get the data into your Java objects, write UI code for editing the Java objects, and sprinkle in code that keeps everything in sync. Lots of repetitive code, with many opportunities to make small mistakes that would be hard to find or debug.

Enter Angelo - he took the Eclipse data binding framework and implemented observables that work against w3c DOM nodes directly, resulting in suprisingly concise code. This is one of those things that you have to see in action to "get" it, an ideal topic for a screencast.

Last night, I decided to learn how to make screencasts by using this as a warm-up exercise. The result turned out pretty amateurish. I apologize for all the "erm"s and that you can hear me breathe, but I think it's still worth watching. Click to watch the screencast (five minutes, 7 MB).

Btw - Angelo, congratulations on becoming an e4 committer!

UI programming BoF at EclipseCon?

2008-02-27T10:01:00.002-07:00

Better late than never, I submitted a BoF proposal today. Comments and suggestions welcome:

UI Component Programming Best Practices

This BoF is about sharing best practices for programming of user interface components. With "component" we mean a piece of code that implements the inner parts of dialogs, wizard pages, views, or editors.

How do we program user interface components today? How could it be made easier, less error-prone, and less complex? Topics discussed in this BoF may include SWT, Nebula, JFace, declarative UIs, data binding, and techniques for ensuring testability of UI components.

Programming of user interfaces at the level of RCP or the Workbench (where you assemble UI components into plug-ins and applications) are out of scope for this BoF.

Looking for feedback: nested attributes in tables

2007-12-06T12:06:00.000-07:00

Data binding makes it relatively easy to set up a table displaying 'live' data. You don't have to implement any listeners yourself. The first step is to use ObservableListContentProvider or ObservableSetContentProvider, and an observable set or list as the viewer's input. Then you can use ObservableMapLabelProvider to define the columns in your table.

But what about nested attributes in a table? For example, if you are writing a genealogy application, you would want to display the father's and mother's name in a table like this:

The 'tricky' part of this is that the cells for Mother and Father need to update on two conditions - when the name of a father or mother changes, or when the parent relationship between two persons changes.

I have a patch that implements this and a new snippet, and am looking for feedback. See bug 196785.

Note that this is only the low-level machinery; we have some thoughts about making this easer to set up in bug 144260.

Getting rid of those pesky "Could not attach listener to " log messages

2007-10-31T21:29:00.000-06:00

If you've ever received...


Could not attach listener to org.eclipse.jface.examples.databinding.snippets.Snippet000HelloWorld$Person@92668c
java.lang.NoSuchMethodException: org.eclipse.jface.examples.databinding.snippets.Snippet000HelloWorld$Person.addPropertyChangeListener(java.beans.PropertyChangeListener)
 at java.lang.Class.getMethod(Class.java:986)
...

and then asked...

"Why is this exception being logged?"

and we said...

"Because your object is not a Bean."

and you said...

"Correct. But I don't want that logged."

and we said...

"Well, if it's not a Bean then BeanObservables might not be the correct thing for you."

and you said...

"So what is the correct thing for me?"

and we said...

"It doesn't exist. Roll your own."

and you said...

"!@#$%^%@#$%!"

We heard your cries and created PojoObservables. It does everything that BeansObservables does except that it doesn't register PropertyChangeListeners. As a result it won't respond to changes in the POJO but it provides IObservable* implementations to be used in Bindings. It makes its first appearance in 3.4M3 as a result of bug 198201.

JFace Data Binding Conformance Tests

2007-09-30T17:36:00.001-06:00

I'm a bit of a test junky. I don't necessarily enjoy writing them but I can't do without them. They're a necessity and I consider a team's attitude toward unit testing a metric of assessing a project's health. One of my post 1.0 ambitions was to create a solid testing infrastructure to ease the burden of writing tests for JDB and to not start over every time a new observable is written. Another part of this was that I wanted to expose the infrastructure to our consumers so that you don't have to duplicate the some of the tediousness we have gone through in order to ensure the proper behavior of our implementations.

As a result org.eclipse.jface.tests.databinding.conformance has been created. An introduction of the ideas and how to consume the project can be found on the Eclipse Wiki at JFace Data Binding/Conformance Tests. The main idea is that you provide a delegate that allows us to interact with your observable. You then select the TestCases to run and we will handle the rest. The conformance tests are JUnit3 based and should integrate into any existing JUnit testing framework. The project should be considered alpha and 1.0 is tentatively scheduled to be released with Eclipse 3.4. Any and all feedback is welcome.

Happy testing.

Post 3.3 and 3.4M1 Conversations

2007-08-21T19:40:00.001-06:00

It took us on JFace Data Binding a little while to get going again after our 1.0 release because of all the normal reasons: the Europa release, summer vacations, and a rare debilitating ear infection. But things have been pretty active recently in the world of JFace Data Binding and I figured I'd blog a bit about a few of the current conversations.

3.3.1 maintenance fixes: We haven't seen many issues with the 1.0 release but if you run into any please log them as soon as possible. If you have logged one that you think should go into 3.3.1 ping us again on the bug with a comment saying you think it should go in 3.3.1.(bugzilla query)
Support for converting and validating Java 5 data types: One of the limitations of the 1.0 release is that org.eclipse.core.databinding can only depend upon types found in the CDC 1.0. Because of this we only provide default support for types found in the CDC. This is less than ideal for those of us who are developing against >= Java 5 JDK. If you have added support in your own code for these types and would like to see them in the JDB core feel free to log enhancement requests (with patches!) or reopen existing ones so that we can get everything we can in for 3.4.(bug 197798)
Simplify API to observe nested attributes: The master detail APIs work well but could use some simplification.(bug 196785)
Creation of conformance tests: In order to speed up and raise the quality of development of observables we're planning on exposing conformance tests. These will be public and in their own plug-in so that whether you're writing an observable for your own object or contributing to JDB you'll have a suite of ready made tests to run. These tests will assert that any observable conforms to the defined contract. (bug 182059)

Observe Multiple Selections of Viewers

2007-08-21T19:24:00.000-06:00

Thanks to Peter Centgraf and Boris we now have the ability to observe multiple selections in Viewers. To take it for a test drive check out org.eclipse.jface.databinding from HEAD and take a look at ViewersObservables.observeMultiSelection(ISelectionProvider selectionProvider). Technically you can observe the selection of any ISelectionProvider with the API, not just Viewers.

bug 124683

See a bug, log a bug

2007-07-29T11:47:00.000-06:00

A little word of advice to anyone who thinks they have found a bug in JFace Data Binding. After performing due diligence and the behavior seems to be incorrect, disagrees with the documentation, etc. log a bug. For some there's a tendency to post to the newsgroup with "Is this a bug?" somewhere in the message. This is OK to do but it's not necessary. If you think you have found a bug go ahead and log it to bugzilla. If it ends up not being a bug we'll close it as WONTFIX or INVALID, depending upon what is appropriate. This is actually easier on us, the committers and contributors, as we don't have to monitor multiple outlets for bugs. If you still aren't comfortable with going directly to bugzilla go ahead and post to the newsgroup. But if there is no answer for a day or two go ahead and log it to bugzilla.

Also don't take a resolution of INVALID or WONTFIX as a slap in the face or as anyone saying "you shouldn't have logged this". These are perfectly valid resolutions and are an acceptable way to declare that we disagree with the assertion or that our library is not the appropriate place for the functionality. Basically don't allow these resolutions to keep you from logging other bugs. There is never a negative tone attached to a resolution. If we think that the question should have initially gone to the newsgroup we'll say so. Don't get me wrong, bugzilla is not the newsgroup. You should ask "how do I?" sort of questions there. But if you have found a bug don't hesitate to log it to bugzilla.

Keep up the bug reports, enhancement requests, newsgroup posts, and feedback. We appreciate every bit of it.

QSEclipse Blog

2007-06-24T16:40:00.000-06:00

I created a blog for QSEclipse so that I don't end up creating off topic posts here... after this one. I'm not working on the project often but when something frustrates me enough I just can't help myself. When I make releases I'll post to the blog and also try to blog about anything I think is relevant in its development since the Quicksilver APIs are largely undocumented and is not open source.

QSEclipse Blog

EMF Observable Support

2007-03-29T08:34:00.000-06:00

One of the recurring requests is for JFace Data Binding IObservable implementations for EMF. A lot of folks out there use EMF for their model and would like to hook that up with all the binding goodness of JFace Data Binding. If you have that itch you might want to follow bug 75625.

Review JFace's data binding design to determine how best to exploit it
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75625

3.3M6 JFace Data Binding API Changes

2007-03-26T09:21:00.000-06:00

3.3M6 was the API freeze and JFace Data Binding had a few changes in regards to API that were necessary for 1.0. All API changes can be found with this query. The most dramatic changes can be found in bugs 175840 and 177463.

175840 - [DataBinding] Remove BindingListener/BindingEvent from the API

The title doesn't quite do this justice. The change that will effect most consumers is that we removed BindSpec and the configuration of bindings has changes because of this. We have introduced 2 new classes to replace BindSpec: UpdateValueStrategy and UpdateListStrategy.

177463 - [DataBinding] SWT Observable API additions

The essence of this change is that all SWTObservables.observe*(...) methods are now untyped meaning they all accept a type of Control. This was done in anticipation of supporting multiple SWT versions. If we were to put the latest and greatest widgets in the method signatures it would prohibit us from using this class with Eclipse 3.2.

Monitoring JFace Data Binding Wiki Changes

2007-03-02T21:51:00.000-07:00

Since Eclipsepedia is publishing recent changes I threw together a quick Yahoo Pipe to monitor changes to the JFace Data Binding articles. Our wiki documentation is going to be changing quite a bit and hopefully soon. If interested this is one way to keep track of those changes.

JFace Data Binding Wiki Changes

Update: This isn't working at the moment. When I can find some time I'll update the pipe.

Eclipsepedia Recent Changes Feed

2007-03-02T18:35:00.000-07:00

My thanks go out to whoever got this working. When this popped up in NetNewsWire it made my day.

Eclipsepedia
Eclipsepedia Recent Changes

Quicksilver + Eclipse = QSEclipse

2007-02-19T22:29:00.000-07:00

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

2007-02-19T01:11:00.000-07:00

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

2007-02-13T21:14:00.000-07:00

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

2007-02-11T15:27:00.000-07:00

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

2007-01-20T10:44:00.000-07:00

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

BindingEvent.PIPELINE_AFTER_GET - retrieve target value

BindingEvent.PIPELINE_AFTER_VALIDATE - validate target value

BindingEvent.PIPELINE_AFTER_CONVERT - convert target value to model type

BindingEvent.PIPELINE_AFTER_BUSINESS_VALIDATE - validate converted value

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:

BindingEvent.PIPELINE_AFTER_GET - retrieve target value

BindingEvent.PIPELINE_AFTER_CONVERT - convert target value

BindingEvent.PIPELINE_BEFORE_CHANGE - a placeholder for expensive validation

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

2007-01-10T20:02:00.000-07:00

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.

Observe changes of the viewer's selection.

Observe the name property of the selection.

~~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:

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

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

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...

you need to observe container.master.detail

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

2007-01-10T18:03:00.000-07:00

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.

Master Detail - Selection

2007-01-09T21:00:00.000-07:00

I find myself answering quite a few questions on the newsgroup hinting that the solution is the master detail APIs. I figured that a verbose explanation couldn't hurt the cause. The stereotypical master detail use case contains a list and upon selection in the list details will be displayed in a separate set of widgets. I'll attempt to explain the core concepts involved.

To explain we'll use the master detail snippet available in the data binding examples project. The snippet displays an SWT List filled with Persons. The Person model has one property, name. Upon selection in the List the name of the currently selected person is displayed in a Text widget.

The relevant data binding code is copied and pasted below...

// 1. Observe changes in selection.
IObservableValue selectionObservable = ViewersObservables
    .observeSingleSelection(viewer);

// 2. Observe the name property of the current selection.
IObservableValue detailObservable = BeansObservables
    .observeDetailValue(Realm.getDefault(), selectionObservable, "name",
        String.class);

// 3. Bind the Text widget to the name detail (selection's name).
new DataBindingContext().bindValue(SWTObservables.observeText(name,
    SWT.None), detailObservable, new BindSpec().setUpdateModel(false));

If you follow the comments in the snippet you'll see that we need to perform 3 steps:

Observe changes of the viewer's selection.

Observe the name property of the selection.

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

1. Observe changes in the viewer's selection

IObservableValue has a value. I know, rocket science. But what IObservableValue provides us is a reference to a transient instance and we can observe changes from one instance to the next. If the selection of the viewer is a person the value of the selection observable will be this person. If the selection is null the value of the selection observable will be null. Regardless of the value we have a reference to an object that will contain the viewer's selection. Change events will fire when a new person, or null, is set as the value of this observable. This is the master.

2. Observe the detail of the master (name of the selected person)

When we observe a detail of the master we're effectively saying...

"observe the value of a property of the value contained in an observable".

Translated into our use case we're saying...

"observe the value of the name property of the person contained in the selection"

If the selection of the the Viewer is a Person with the name "mickey mouse" the following will be true...

selectionObservable.getValue() == Person("mickey mouse")

detailObservable.getValue() == "mickey mouse"

When the selection changes to a Person with the name of "daffy duck" the following will be true...

selectionObservable.getValue() == Person("daffy duck")

detailObservable.getValue() == "daffy duck"

When the selection changes to null the following will be true...

selectionObservable.getValue() == null

detailObservable.getValue() == null

When the master value changes the detail populates itself with the value from the master. This gives us the master detail behavior. To finish it off we need to...

3. Bind the detail to the Text widget

The last step is to bind the detail observable to the Text widget in order to display the detail. Enough said.

Tomorrow night I'll describe a use case that explains how this fits into using JFace Data Binding and the presentation model design pattern.

JFace Data Binding is Eclipse 3.2.x compatible

2006-12-09T15:55:00.000-07:00

As of 20061209 the data binding projects are compatible with Eclipse 3.2, this will be in 3.3M4. There weren't major issues, just compilation errors from using a couple 3.3 APIs. But they're now fixed and we jive with 3.2 as well as 3.3. The goal is to stay compatible with 3.2 as long as it isn't prohibitive to the projects. We'll do our best to keep it 3.2 compatible. If we can get to it we will be attempting to use the 3.3 viewer APIs when creating builders for viewer bindings. When that occurs we'll try to come up with a 3.2 compatible way to handle this as well.

See bug bug 164134 for details.

Minor API changes before 3.3M4

2006-12-04T22:38:00.000-07:00

We're getting close to 3.3M4 (Friday Dec. 15, 2006) when we're hoping to have all API changes to JFace Data Binding complete. The changes are minor but if you're using the current code you might want to peruse the list to determine if you'll be effected.

bug 118429 - IValidator will now return IStatus instead of a string.

bug 147530 - Event notifications on observables will pass an event object rather than the the source and diff as separate parameters.

bug 164653 - Changes to the protected APIs in the abstract observable implementations for thread safety.

bug 128142 - IDomainValidator is being replaced with IValidator.

Again, they're all pretty minor and shouldn't take long to correct in consuming code.

Also we had a team meeting on November 30th, 2006. The notes can be found here. We tried to record the audio but alas, the service was having issues that night.

20061212 Update:
Another small change has occurred on the race to 3.3M4.

bug 167450 - remove BindSupportFactory, a couple of methods are now gone from DataBindingContext

EclipseCon 2007 Data Binding Long Talk

2006-11-29T22:45:00.000-07:00

If you have an interest in learning about binding some data, being data bound, being bound and... I got nothing... please vote for the Introduction to Eclipse Data Binding long talk being proposed for EclipseCon.

Straight from the horse's mouth:

"It’s new, it’s cool, and it helps you write better code!"

I soooooo want to write better code; I'm game. Please vote!

Master Detail Sequence Diagram

2006-11-12T18:29:00.000-07:00

One of the new packages in HEAD is org.eclipse.core.databinding.observable.masterdetail. It contains observable implementations that provide master detail behavior. This can be a little confusing at first glance so I thought I'd take a shot at creating a sequence diagram to describe the inner workings. Possibly this, or some form of it, will get worked into our documentation but I thought I'd throw it out there for anyone looking at the latest API.

Comments are greatly appreciated. Also if someone knows where I can get a higher resolution Eclipse logo I'd appreciate the tip.

Project renaming and removal of provisional API

2006-11-12T13:36:00.001-07:00

On Friday the concurrency branch, Bug116920_investigation, was merged into HEAD and the projects have also been renamed. This means that Realms are now in HEAD and most provisional API has been removed. What that means is that with HEAD your code probably doesn't compile.

Project Renaming

org.eclipse.jface.databinding -> org.eclipse.core.databinding

org.eclipse.jface.databinding.beans -> org.eclipse.core.databinding.beans

org.eclipse.jface.databinding.ui -> org.eclipse.jface.databinding

org.eclipse.jface.examples.databinding

org.eclipse.jface.tests.databinding

Realms

Realms deserve more than a blog post so I'm going to leave this until later; there will be documentation on the subject. To see what has led us down this path see bug 116920. Take a look at the examples and tests projects for usage. There's also a ThreadRealm and LockRealm implementation in the tests projects.

Provisonal API Removal

The majority of the consumer code that could be broken is the result of the removal of the provisional API. The majority of that API existed to allow for the binding of viewers to a model. Previously the only API that the consumer had for this was a builder that then took care of creating the label and content providers. We don't yet have replacements for the builders but we have API for content providers and label providers which can be used to bind viewers without a builder. By exposing these classes this allows for flexibility that we didn't previously have. Consumers now have access to the label provider and can create a decorator to provide colors, fonts, images, etc. as well as the text. Below is a quick example of the creation of the label and content providers for a ComboViewer.

    1 //Create the observable for the domain list.
    2 IObservableList lodgings = BeansObservables.observeList(Realm
    3     .getDefault(), catalog, "lodgings");
    4 //Create the content provider that corresponds to the observable list.
    5 ObservableListContentProvider contentProvider = new ObservableListContentProvider();
    6 
    7 //Create a mapping for the attribute to display.
    8 IObservableMap[] attributeMaps = BeansObservables.observeMaps(
    9     contentProvider.getKnownElements(), Lodging.class,
   10     new String[] { "name" });
   11 
   12 cviewer.setContentProvider(contentProvider);
   13 cviewer.setLabelProvider(new ObservableMapLabelProvider(attributeMaps));
   14 cviewer.setInput(lodgings);

The key to this is the creation of the attributeMaps (line 8). In this case we're only specifying one attribute, name (line 10), because it's a Combo. In the map returned the key will be the element and the value will be the display value of the name attribute of the element.

Stay tuned, it's going to be a busy next couple of months.

A Focus on Data Structures

2006-11-06T21:16:00.000-07:00

HEAD hasn't had many changes lately for data binding because of the 3.3M3 release. But this doesn't mean that nothing has been happening. Changes have been occurring in the concurrency branch (Bug116920_investigation) for, you guessed it, concurrency. But the branch has also been used for removing provisional packages and the refactoring of some of the provisional code into API. But before I get into the other changes it's very important to us that we get as many eyes on the concurrency approach as possible. If you're a concurrency guru or just someone with a interest please read through bug 116920 and provide feedback if you have any.

The other changes that have been occurring are interesting. If you are vaguely familiar with JFace Data Binding you probably know that data binding is comprised of two parts: observables and bindings. The idea behind bindings is pretty straight forward and what you would expect from the name. They bind two entities and provides a MVC-esque flow of data to keep the 2 in sync. This is normally applied in the context of a graphical user interface in order to keep the UI in sync with a model. But there's more that needs to be implemented in order to make this synchronization and this is where observables come in. Observables are an implementation of the observer pattern and they create a common abstraction that allows for the observing of changes in an object. This all begins with IObservable but branches out into:

IObservableValue: Interface for the observing of a single value.
IObservableList: Interface for observing changes in a List. The notifications are notifications of when items are added or removed from the List. If an object being maintained in the List changes events are not fired from the IObservableList implementation.
IObservableSet: Interface for observing changes in a Set. Like IObservableList the change events are for items being added and removed from the Set.
IObservableMap: Interface for observing changes in a Map. And you guess it, same type of behavior as the previous interfaces but for a Map.

For all of the above interfaces there are default mutable, or writable, implementations.

WritableValue

WritableList

WritableSet

WritableMap

By providing these implementations we, and any consumer, can use the observable implementations for any need that arises. The need doesn't have to be for binding a widget to a model, it can be any use case that you're wanting to provide notifications for a data structure. The idea is that the abstraction should feel common and also provide building blocks, just like the Collections Framework, for application needs.

In order to drive home the idea that the core of data binding doesn't necessarily have anything to do with UI the core interfaces and implementations that are UI unaware will reside in plug-in org.eclipse.core.databinding. The project is currently named org.eclipse.jface.databinding but will soon be renamed, see bug 153630 for details.

Changing to the eclipse.platform newsgroup

2006-10-27T20:01:00.000-06:00

We're changing the official JFace Data Binding newsgroup from eclipse.platform.rcp (http://, news://) to eclipse.platform (http://, news://). The reason is that we feel like it's a little more intuitive as the plug-in isn't part of RCP and is a platform project. We'll still monitor the RCP newsgroup but in the future please post your questions to eclipse.platform. Also please remember to prefix the summary with "[DataBinding]" to make posts easier to find. For more information see bug 161885.

JFace Data Binding Google Search

2006-10-24T07:07:00.000-06:00

I started a Custom Google Search for JFace Data Binding.

JFace Data Binding Google Search

Update:
I've done some tweaking and added the following refinements:

bugs: Searches bugzilla for the entered text and adds "[DataBinding]" to the search as all Data Binding bugs contain this in the title.
cvs: Search CVS and CVS commit messages.
forums: Searches eclipsezone.com/forums and the platform-ui-dev mailing list adding 'databinding OR "data binding"' to narrow the search.

When using any refinement it limits the searches to the sites I have listed for the refinement rather than just favoring the listed sites.

The main search searches the following sites:

http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/

http://cia.navi.cx/stats/project/eclipse/org.eclipse.jface.examples.databinding

http://cia.navi.cx/stats/project/eclipse/org.eclipse.jface.tests.databinding

http://cia.navi.cx/stats/project/eclipse/org.eclipse.jface.databinding.beans

http://cia.navi.cx/stats/project/eclipse/org.eclipse.jface.databinding.ui

http://cia.navi.cx/stats/project/eclipse/org.eclipse.jface.databinding

http://www.eclipsezone.com

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.tests.databinding

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.examples.databinding

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.databinding.ui

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.databinding.beans

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jface.databinding

http://bugs.eclipse.org/bugs

http://wiki.eclipse.org

http://fire-change-event.blogspot.com

http://www.coconut-palm-software.com/the_visual_editor

http://borisoneclipse.blogspot.com

http://jroller.com/rss/trisa

This works nicely when combined with Firefox's keyword search or SafariStand's quick search.

Pardon our Progress: BindSpec and provisional APIs

2006-10-23T20:23:00.000-06:00

A couple of people have run into issues lately attempting to use the provisional APIs in the latest version of Data Binding. They receive an exception along the lines of...


Exception in thread "main" org.eclipse.jface.internal.databinding.provisional.BindingException: No binding found for target: org.eclipse.jface.internal.databinding.internal.swt.TextObservableValue, model: org.eclipse.jface.databinding.observable.value.WritableValue

 at org.eclipse.jface.internal.databinding.provisional.DataBindingContext.bind(DataBindingContext.java:170)

 at org.eclipse.jface.internal.databinding.provisional.DataBindingContext.bind(DataBindingContext.java:228)

The issue is that the incorrect BindSpec has been passed to DataBindingContext.bind(...). But how can that be? Shouldn't the API enforce the correct type? Yes, well most of the time is should...

The signature for bind(...) is as follows...


 public Binding bind(Object targetDescription,Object modelDescription, org.eclipse.jface.databinding.BindSpec bindSpec)

The method expects an instance of org.eclipse.jface.databinding.BindSpec. This is the 1.0 BindSpec. The problem is that internally if bind(...) doesn't receive an instance of org.eclipse.jface.internal.databinding.provisional.BindSpec, the provisional BindSpec, it won't create the Binding. The reason for this confusion is that we're trying to keep the provisional APIs working while refactoring to the 1.0 APIs. So even though the signature of the bind(...) method accepts org.eclipse.jface.databinding.BindSpec don't pass this type, pass org.eclipse.jface.internal.databinding.provisional.BindSpec instead.

So let's recap, when using the provisional DataBindingContext...

org.eclipse.jface.databinding.BindSpec == bad

org.eclipse.jface.internal.databinding.provisional.BindSpec == good

For more information see bug 161498.

Uber Factories and Project Refactoring

2006-10-17T20:00:00.000-06:00

It would be difficult to try to sum up what has happened in Data Binding up until this point. So I thought I'd highlight a few changes/discussions that have occurred recently. In case you don't know we're on the road to the 1.0 release. One area that we're focusing on is API. I'll do my best to point out changes in the API.

bug 147563 - [DataBinding] Need a standard factory for data binding contexts

API Changes

"Those who already smoked the weed of the Überfactory and can't give up are advised to roll their own factories, or move to stronger stuff like e.g. AOP.""

- comment 75

If you are familiar with the Eclipse 3.2 version of Data Binding you might be familiar with the "Uber factories" that were used to create IObservables and Bindings. The factories, IBindingFactory and IObservableFactory, have been deprecated as we decided to keep the API simple and expressive in order to allow for transparency, simpler debugging, and better documentation. Currently there is SWT support using the new approach but we haven't moved the JFace support to the new API yet. For examples of the approach see SWTObservables and BeansObservables. Also, before the 1.0 release the static factory methods on SWTObservables will be changed from having a "get" prefix to an "observe" prefix.

bug 153630 - [DataBinding] Extract SWT specific code from JFace databinding into its own bundle

As of 20061004 what was org.eclipse.jface.databinding has been broken out into 3 separate plug-ins. The core framework no longer has SWT dependencies. The projects and their dependencies are as follows:


org.eclipse.jface.databinding "core data binding framework"
class library: J2ME Foundation 1.0
dependencies:
 org.eclipse.equinox.common

org.eclipse.jface.databinding.ui "binding to SWT and JFace"
class library: J2ME Foundation 1.0
dependencies:
 org.eclipse.jface.databinding
 org.eclipse.equinox.common
 org.eclipse.jface

org.eclipse.jface.databinding.beans "binding to Java beans"
class library: J2SE 1.4
dependencies:
 org.eclipse.jface.databinding
 org.eclipse.equinox.common

Spreadsheet Example

Boris has been working on a Spreadsheet implemented using Data Binding. It's an interesting example that uses ComputedValue in case you'd like to see it in action.

bug 116920 - [DataBinding] need to handle model change events which don't happen in the UI thread

It looks like progress is being made on the concurrency front. If you have any input/concerns on concurrency in the framework please add them to the bug. The issue is that the framework is not thread safe and if possible we'd like it to be for the 1.0 release.

We have a FAQ

A FAQ has been started on Eclipsepedia.

The goal of fireChangeEvent()

2006-10-17T19:59:00.000-06:00

This blog is for those interested in recent activity in the Eclipse JFace Data Binding project. The posts will be comprised of recent CVS commits, bug changes/resolutions, and any activity that might be of interest to those tracking the project. The goal is to cut down on the amount of work you have to do to know what's going on so that you can spend more time on using the toolkit and preparing yourself for what's coming. I'll try to keep things short and sweet. In that spirit, on to the first post.