JFace Data Binding is Eclipse 3.2.x compatible

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

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.

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


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


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


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

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

EclipseCon 2007 Data Binding Long Talk

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

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

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

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

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

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

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

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()

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.