UI programming BoF at EclipseCon?

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

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

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

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

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

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

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.