Eclipse Demo Camp 2010 - UI Bindings - An Introduction

UI Bindings - An Introduction Presentation by Tonny Madsen at Eclipse Demo Camp in Copenhagen 1. December 2010

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.

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

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!

Demo
How does it look like..

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

The Shop Model

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

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

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

If You Want to Know More about UI Bindings
The Project:
http:// code.google.com/a/eclipselabs.org/p/ui -bindings

Eclipse Demo Camp 2010 - UI Bindings - An Introduction

by Tonny Madsen on Dec 02, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 20

Statistics

Eclipse Demo Camp 2010 - UI Bindings - An Introduction — Presentation Transcript