Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

EclipseCon '09 - The Happy Marriage of EMF, Data binding, UI Forms and Field Assist in larger RCP Applications

on

  • 1,748 views

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 ...

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?

Statistics

Views

Total Views
1,748
Views on SlideShare
1,748
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

EclipseCon '09 - The Happy Marriage of EMF, Data binding, UI Forms and Field Assist in larger RCP Applications EclipseCon '09 - The Happy Marriage of EMF, Data binding, UI Forms and Field Assist in larger RCP Applications Presentation Transcript

  • 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?
  • 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!
  • 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
  • The Project
    • The project is hosted at Google Code
      • http://code.google.com/p/rcp-company-uibindings/
    • EPL license
    • Participation is always welcome