eclipse demo camp 2010 - ui bindings - an introduction
DESCRIPTION
Presentation from Eclipse Demo Camp 2010 in Copenhagen.TRANSCRIPT
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