Imagine you have to develop a larger Eclipse RCP based application with many dozens - maybe hundreds - of views, dialogs and wizards all based on a large common EMF based data model. How do you make sure you get a consistent and modern interface that can be extended in the future without redesigning everything again and again?

1. PR0006 - 2008-01-28
Redistribution and other use of this material is covered by EPL.
The Happy Marriage of EMF, Data binding, UI Forms and Field Assist
in larger RCP Applications
Imagine you have to develop a larger Eclipse RCP based application with
many dozens - maybe hundreds - of views, dialogs and wizards all
based on a large common EMF based data model. How do you make
sure you get a consistent and modern interface that can be extended in
the future without redesigning everything again and again?

2. 2
The Problem – Consistency and Maintainability
 Consistency
 Cornerstone of all UI Design Guides
 If you can do it for one widget, you should be able to do it for all
widgets!
 Maintainability!
Guideline 1.1:
Follow and apply good user interface design principles: user
in control, directness, consistency, forgiveness, feedback,
aesthetics, and simplicity.

3. 3
The Problem – rephrased
 Basically, how do you solve these common problems:
 all currencies, amounts, dates, customer IDs and whatever are
shown in the same manner all over the application
 all date fields support the same set of shortcuts for "today", "next
week", "next weekend", etc.
 all enumeration fields of the same base type are mapped in the
same manner - whether a combobox, list or simple text field is
wanted in a specific form
 all forms use the same colors, fonts and images
 the application can still be developed using both automated UI
generation and existing commercial UI design tools
 when new UI ideas are developed they can be added to the
application without having to redo all forms again
 the UI can utilize the current UI Forms, EMF validators, and field
assist without having to hand code everything repeatably
 the developed code does not contain too much boilerplate code for
the UI

4. 4
Three Approaches
 New custom widget set that adds semantics to the basic SWT widgets
 Knows how to search for a customer, etc
 Disadvantages:

What about tables and trees

A value is often not enough

Cannot use any existing UI design tools
 Modeling the UI in a DSL – usually XML – and then generate the widget
tree at build time or run-time
 Disadvantages:

Special case code can be hard to add

Cannot use any existing UI design tools
 Java code with a decorator pattern
 The UI Bindings framework does not preclude you from modeling the UI
in XML!

5. 5
Design Philosophy
 Java rather than XML
 Though we still have a lot of extension points
 The Model is… EMF
 Other real-life models are possible – e.g. the data binding framework
supports Java Beans
 Utilizes EMF meta information like bounds and annotations
 Add-on Functionality as Add-on Classes
 Keeps the core functionality as simple as possible
 Though it is probably more complicated than need be
 Avoid hard-coded limitations
 Extensibility via extension point: UI attributes, decorators,
observable factories, model annotations

6. 6
The Shop Model

7. 7
The Internals
 UI Attributes
 Provides a common interface to widgets in the form of

A number of observables: value, list, min and max value, etc

A field assist adapter

A number of properties
 Decorators
 Binds a single model (EMF) attribute to a single UI attribute
 Decorator Providers
 Provides a decorator based on the “types” of the model attribute and
the UI attribute (and a type specification)
 Model Annotations
 Provides additional information about specific (EMF) entities and
features

8. 8
Model Annotations
 Arguments for decorators
 Tooltips, read-only
 Min and max values
 Valid values for lists
 Can be specified in several places
 As EMF annotations
 As UI Binding Model annotations
 In specific bindings

9. 9
Eclipse Technologies
 EMF
 Domain model
 Internal model
 UI Forms
 Used to generate the forms, wizards, etc
 EMF Validation
 Used to provide non-trivial validation
 Data Binding
 All bindings to widgets
 Field Assist
 Quick Fixes

10. 10
The Project
 The project is hosted at Google Code
 http://code.google.com/p/rcp-company-uibindings/
 EPL license
 Participation is always welcome