Description David J. Orme 2004-09-20 16:13:54 EDT

The existing JFace architecture is very flexible for presenting and editing all
kinds of data.  However, this flexibility comes at a price: one must currently
write quite a bit of code in order to implement a TableViewer or a TreeViewer in
their application.  However, it is important that any solution to this problem
gain convenience without losing flexibility or dropping backward compatibility
with the existing implementation.

In this bug report, I propose to enhance the existing viewer framework by
including a standard set of Providers that use reflection to marshall and
unmarshall their data.

The existing viewer framework is remarkable in its flexibility.  One can use it
to edit literally any model that one can imagine, even those that don't natively
conform to the structure that the viewer would naturally expect.  That is, by
writing an appropriate content provider, one could use a JFace TableViewer to
edit search results, or to display aggregated totals.

The following classes and interfaces are used by JFace to generically access,
display, and edit arbitrary data structures:

* CellEditor
* ICellModifier
* IBaseLabelProvider
* IContentProvider

I contend that it is possible to provide reasonable default implementations for
all of the interfaces as well as a factory class that can use java.lang.Reflect
to analyze a Java data structure and produce a reasonable viewer instance for
editing 80% of Java data structures without writing additional code.

The remainder of this essay will describe the general strategy I would recommend:

I will work from the following assumptions:

1) The user wants to edit 80% of the cases as easily as possible.

2) The user will work with either a factory class that contains methods:

* allowing the user to set a model object to edit
* allowing the user to specify the attributes of each object to edit.
* allowing the user to generate from these specifications a TableViewer,
TreeViewer, etc., that can edit the specified collection according to her
specifications.

We will do this as follows:

Most editing work involves using some Iterator or ListIterator to edit the
contents of a collection.  We don't care what kind of collection it is or where
its data came from, we just care that we can reasonably iterate over its
contents.  We also don't care about how the data is persisted.  Java object
persistence frameworks have been popping up like mushrooms after a rain lately,
and most projects have already adopted one.  So if we can limit the scope of the
problem to editing data that is stored in a plain old Java object (POJO), we can
solve what 80% of people want with 20% of the effort.

In addition, this approach enables the ListIterator interface to be used as a
wrapper interface for all sorts of data that isn't natively in a list format,
such as JDBC database data or Map data.  If you can implement a ListIterator
over your data, you can edit it.

Based on this understanding, one can implement a generic ContentProvider,
CellModifier and LabelProvider that will use Java reflection to return a
collection to edit and actually perform the editing.  One can also implement a
factory object as described above that can specify the attributes of a
collection's objects to edit, and can actually create a TableViewer that can
edit a collection with those attributes with CellEditors in the right places, etc.