Difference between revisions of "UFaceKit"
(→SWT vs UFaceKit)
|Line 21:||Line 21:|
=== Overview ===
=== Overview ===
UFaceKit works on different levels using a layered setup
UFaceKit works on different levels using a layered setupand 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.
Revision as of 13:25, 16 January 2009
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.
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.
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.
On top of this enabling bits UFaceKit provides higherlevel APIs for easier use
and built-in support for advanced features like:
- declarative styleing (e.g. using CSS)
- declarative ui definition using Ecore
- automatic decoration support
The Core Module
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.
Contributing to UFaceKit
- Setting up within Eclipse
- Setting up using Maven
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 ...