Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

UFaceKit

Revision as of 22:18, 16 January 2009 by Tom.schindl.bestsolution.at (Talk | contribs) (Goals / Project Description)

UFaceKit is a project providing an high-level, widget toolkit independent UI-API ranging from SWT over GWT to potentially Android.

The project can currently be split into 2 main working areas

  • The Core Modules
  • The Technology-Specific Modules

which itself once more split into smaller sub-areas

Goals / Project Description

UFaceKits goal is to reduce the development time of datacentric, formbased RichClient- and RichInternet-Applications using native technologies to create the UI on the deployment platform.

A very important aspect of UFaceKit is its use of the Factory pattern to create instance of widget this allows users to easily provide their own factory and e.g. replace SWT-Table through Nebula-Grid. The use of the Factory-Pattern has another important advantage because it provides you the possibilities to add interceptors informing you about the creation of a widget and directly react upon its creation (e.g. adding an auto-completion feature to text input fields).

SWT vs UFaceKit

SWT is already providing a first class implementation to make Java-Applications behave and look native on the deployment platform so why do we invented one more API to do UI-Development in Java. The main "problem" of SWT is that it is designed to abstract the native drawing and widget API from the developer (hence the name SimpleWidgetToolkit) but when it comes to higher level concepts like binding your domain model to your widgets, providing support for declarative styling and declarative UI construction it misses many features you'd expect to be built in into a modern UI-Toolkit.

UFaceKit is working at a higher level abstracting higher-level UI-Concepts similar to JFace but goes further in terms of abstraction and features. One of the main problems of JFace is that it is tightly bound to SWT-API it abstracts. This makes it hard to port the high-level JFace-API to new platforms because it assumes an SWT port is available and because is working at such a low-level it is a huge task port SWT to a new platform if possible at all.

In contrast to this porting UFaceKit to a new platform is much easier because many functions provided by SWT as Java-API are not provided by UFaceKit at the Java-API level but are controlled for example by using Declarative-Styleing.

Overview

UFaceKit works on different levels using a layered setup. First and fore most UFaceKit needs to have an Eclipse-Databinding for Widget and Model-Technologies it wants to use. Some of them are provided by other projects (SWT-Observable, EMF-Observables) and UFaceKit reuses them. For other technologies it provides the implementation as part of the UFaceKit project.

UFaceKit Overview 1.png

On top of this enabling bits UFaceKit provides higherlevel APIs for easier use

UFaceKit Overview 2.png

and built-in support for advanced features like:

  • declarative styleing (e.g. using CSS)
  • declarative ui definition using Ecore
  • automatic decoration support
  • ...

The Modules

The Core Module

The core modules of UFaceKit define the common ToolKit-Independent UFaceKit-API and features like styling and JavaScript expressions.

The Technology-Specific Module

Modules in this section hold technology specifc implementations from generic APIs ranging from UFaceKit-API to Databinding-API for example IObservable implementations for Swing-Controls.

Development

Contributing to UFaceKit

Consuming UFaceKit

Examples Codes

We have a set of Example applications you can take a look at to get started. They exploit all features provided by UFaceKit and you can learn how the we expect UFaceKit to work

  • Addressbook-Example: Small example showing usage of EMF and Declarative Styling
  • ... hopefully more in future ...

Back to the top