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

Difference between revisions of "UFaceKit"

(Goals / Project Description)
(Overview)
Line 7: Line 7:
 
which itself once more split into smaller sub-areas
 
which itself once more split into smaller sub-areas
  
== Overview ==
+
== 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.
 +
 
 +
Porting UFaceKit to a new platform is much easier because many functions provided by SWT as Java-API is not provided by UFaceKit at the API level but is controled 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 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.
Line 22: Line 34:
 
* automatic decoration support
 
* automatic decoration support
 
* ...
 
* ...
 
=== 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.
 
 
Porting UFaceKit to a new platform is much easier because many functions provided by SWT as Java-API is not provided by UFaceKit at the API level but is controled for example by using Declarative-Styleing.
 
  
 
== The Modules ==
 
== The Modules ==

Revision as of 14:22, 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.

Porting UFaceKit to a new platform is much easier because many functions provided by SWT as Java-API is not provided by UFaceKit at the API level but is controled 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