PR0034 - 2010-11-30

Redistribution and other use of this material requires written permission from The RCP Company.

UI Bindings - An Introduction

Presentation by Tonny Madsen at Eclipse Demo Camp in Copenhagen1. December 2010

PR0034 - 2010-11-30

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.

PR0034 - 2010-11-30

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

PR0034 - 2010-11-30

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!

PR0034 - 2010-11-30

5

Demo

How does it look like..

PR0034 - 2010-11-30

6

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

PR0034 - 2010-11-30

7

The Shop Model

PR0034 - 2010-11-30

8

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

PR0034 - 2010-11-30

9

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

PR0034 - 2010-11-30

10

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

PR0034 - 2010-11-30

11

If You Want to Know More about UI Bindings

The Project: http://code.google.com/a/eclipselabs.org/p/ui-bindings