Difference between revisions of "RAP/RWT"

From Eclipsepedia

< RAP
Jump to: navigation, search
(minor formatting)
(RAP Widget Toolkit)
(17 intermediate revisions by 4 users not shown)
Line 1: Line 1:
| [[RAP|RAP wiki home]] | [http://eclipse.org/rap RAP project home] |
+
== Technical Overview  ==
  
==RWT RAP Widget Toolkit==
+
This document describes the technical concepts behind RAP and RWT, the RAP Widget Toolkit. RAP enables the development of Rich Internet Applications using the same programming paradigms that developers know from RCP. It consists of the following components:
  
 +
*'''Server side OSGi and runtime bundles (Equinox):'''<br>One OSGi instance per web application runs in application scope. Different than RCP, RAP has to deal with user sessions. Running an OSGi instance per user-session is not feasible in a scalable way, since the memory consumption in the permanent object space would be beyond any real world resource availability. Therefore bundles are shared between user-sessions.
  
===Introduction===
+
*'''RWT (RAP Widget Toolkit):'''<br>A Widget Library similar to SWT. RWT provides a server-side programming model for a Rich-Web-Client development. Therefore RWT uses an efficient JavaScript Widget Toolkit (a fork of [http://qooxdoo.org Qooxdoo]) that provides rich components on the client site. However, RWT-applications remain Thin Clients (opposed to Fat-Client), since all computations implemented by the application developer are done on the server-side. There is no data model on the client. The request handling is done via AJaX, which leads to a good usability and performance.
  
This document describes the technical concepts behind RWT, the RAP widget toolkit. The availability of a widget toolkit with SWT-API has been a key desire by the community. The RAP team has researched this idea and has come up with the concept of RWT, which combines infrastructure and concepts from W4T with a client side JavaScript framework for UI rendering
+
*'''JFace (RAP version):<br>'''The RAP JFace version is as closely based on the RCP Jface implementation. It provides:<br>
 +
** Viewers
 +
** Dialogs and Wizards
 +
** Actions and Contributions
 +
** Image Registry
  
The RWT implementation is neither finalized nor complete, and the implementation and this document are meant to enable the community to provide feedback.
+
*'''Workbench (RAP version):''' <br>The RAP Workbench is based on the RCP Workbench implementation, but taking multi-user and memory constraints into account. It provides:<br>
 +
** Workbench Windows <br>
 +
** Perspectives
 +
** Workbench Parts
 +
** Selection Service
  
 +
== The RAP Widget Toolkit ==
  
===Technical Overview===
+
RWT (RAP Widget Toolkit) is a GUI widget set that is as similar to SWT as possible. SWT is easy to learn, and anybody who knows SWT should have no problems to build web-front-ends using RWT. Nevertheless there are unavoidable differences between the two libraries - partially caused by the distributed nature of web applications, partially by the strengths and weaknesses of html/css, and limitations of specific browser.
  
RAP strives to enable the development of Rich Internet Applications using
+
To learn more about the differences between SWT and RWT from an application developer point of view, read the RAP Developers Guide. [TODO:LINK!]
the same programming paradigm that developers know from RCP. RAP consists of the
+
following components:
+
  
 +
At runtime, all RWT widgets consist of a server-side Java object, and a client-side JavaScript object presented to the user in HTML/CSS. The application code only interacts with the Java instance, while the user only interacts with the client instance. Like SWT, RWT provides an event model to enable the application programmer to react on user actions like pushing a button. This is different to SWT, as the action has to be submitted to the server, where a action handler will be executed. The communication with the server is done by an AJaX-Request. Beyond the distributed nature of event processing, RWT has to synchronize the widgets client state and server state. This needs to be performed before and after action handlers are executed.
  
Server side OSGi and runtime bundles (Equinox):
+
== LifeCycle ==
* one OSGi instance per web application runs in application scope. Different than  RCP, RAP has to deal with user sessions. Running an OSGi instance per user-session is not feasible in a scalable way, since the memory consumption in the permanent object space would be beyond any real world resource availability. Therefore bundles are shared between user-sessions.
+
 
+
 
+
RWT (RAP Widget Toolkit):
+
* A Widget Library similar to SWT. RWT provides a server-side programming model for a Rich-Web-Client development. Therefore RWT uses an efficient JavaScript Widget Toolkit (Qooxdoo – http://qooxdoo.org) that provides rich components on the client site. However, RWT-applications remain Thin Clients (opposed to Fat-Client), since all computations implemented by the application developer are done on the server-side. There is nothing like a data model on the client. The request handling is done via AJaX, which leads to a good usability and performance.
+
   
+
 
+
Web-JFace provides:
+
* Viewers
+
* Dialogs and Wizards
+
* Actions and Contributions
+
* Image Registry
+
and will be as closely based on the Jface implementation as possible.
+
 
+
 
+
A Web-Workbench provides:
+
* Workbench Windows
+
* Perspectives
+
* Workbench Parts
+
* Selection Service
+
and will be as closely based on the Workbench implementation as possible, taking multi-user and memory constraints into account.
+
 
+
==Details==
+
 
+
 
+
===RAP Widget Toolkit===
+
 
+
As RAP targets developers that are familiar with RCP, RWT is created as a GUI widget set
+
that is as similar to SWT as possible. Anybody who knows SWT should have no
+
problems to build web-front-ends using RWT. Nevertheless there are unavoidable differences
+
between the two libraries - partially caused by the distributed nature of web applications,
+
partially by the document structure of html.
+
 
+
Like SWT RWT provides an event model to enable the application programmer to react on
+
user actions like pushing a button. This is different to SWT, as the action has to be
+
submitted to the server, where a action handler will be executed. The communication with the server is done by an AJaX-Request. Beyond the distributed nature of event processing RWT has to deal with the synchronization of user input and widget-state-with the server side, as the UI state is represented by objects on the server.The synchronization between client state and server state needs to be performed before action handlers can be executed.
+
 
+
 
+
===LifeCycle===
+
  
 
To meet this requirements RWT divides a http-request into different phases that are executed
 
To meet this requirements RWT divides a http-request into different phases that are executed
Line 66: Line 36:
 
Prepare UI Root,Read Data,Process Action and Render.
 
Prepare UI Root,Read Data,Process Action and Render.
  
* '''Prepare UI Root:''' currently responsible for invoking entry points. Implementations of IEntryPoint represent the UI creation entry points (these take over the functionality of a main function used to start a SWT-applictations).
+
* '''Prepare UI Root:''' Currently responsible for invoking entry points. Implementations of IEntryPoint represent the UI creation entry points (these take over the functionality of a main function used to start a SWT-applictations).
  
* '''Read Data:''' request parameters that contain status information belonging to certain Widgets will be applied to those widgets. If an user has entered some characters into an input-type text field that represents a server-side Text control, these characters are transmitted to the text-attribute of the Text instance in this phase.
+
* '''Read Data:''' Request parameters that contain status information belonging to certain Widgets will be applied to those widgets. If an user has entered some characters into an input-type text field that represents a server-side Text control, these characters are transmitted to the text-attribute of the Text instance in this phase.
  
* '''Process Action:''' is the phase where the requested user-action takes place. User actions are triggered for example by clicking a push-button. Application programmers implement and register listeners at the corresponding widget (e.g. a SelectionListener for a Button), to react to such events.
+
* '''Process Action:''' This is the phase where the requested user-action takes place. User actions are triggered for example by clicking a push-button. Application programmers implement and register listeners at the corresponding widget (e.g. a SelectionListener for a Button), to react to such events.
  
* '''Render:''' is where the markup or javascript assignments are created, which will be sent to the browser. During the actual rendering no changes of the widget-tree will happen - neither creation or addition of new widgets nor changing of attributes of existing ones. The AJaX-rendering-mode only creates assignments of those widget-attributes that were changed during the request-processing. This results in a minimal amount of information that needs to be exchanged between server and client.
+
* '''Render:''' This is when the javascript code (as of RAP 1.5, JSON) is created, which will be sent to the browser. During the actual rendering no changes of the widget-tree will happen - neither creation or addition of new widgets nor changing of attributes of existing ones. The AJaX-rendering-mode only creates assignments of those widget-attributes that were changed during the request-processing. This results in a minimal amount of information that needs to be exchanged between server and client.
  
 
+
== Widgets ==
===Widgets===
+
  
 
Considering the already said, RWT-Widgets must meet the following objective: They have to provide  
 
Considering the already said, RWT-Widgets must meet the following objective: They have to provide  
 
a well known API but deal transparently with the lifecycle mechanism. To achieve this the
 
a well known API but deal transparently with the lifecycle mechanism. To achieve this the
RWT-Runtime creates adapters for each widget. Therefore each widget is composed of three parts at runtime:
+
RWT-Runtime creates adapters for each widget. Therefore each widget is composed of three server-side parts at runtime:
  
* the widget instance, contains status information set by the programmer via the widget's API.
+
* The widget instance, contains status information set by the programmer via the widget's API.
* a widget adapter instance, contains additional status information used by the runtime (e.g. information needed to decide whether a widget attribute has changed during the request processing and  whether the new value must be sent to the client or not)
+
* A widget adapter instance, contains additional status information used by the runtime (e.g. information needed to decide whether a widget attribute has changed during the request processing and  whether the new value must be sent to the client or not)
* a shared instance of an lifecycle adapter. Each widget type has an own type of LCA. The LCA is a stateless callback handler used by the RWTLifeCycle to synchronize the widgets state with the client changes, call events etc.
+
* A shared instance of an lifecycle adapter. Each widget type has an own type of LCA. The LCA is a stateless callback handler used by the RWTLifeCycle to synchronize the widgets state with the client changes, call events etc.
 
+
Depending on the clients capability there will be two peculiarities of LCAs in the final
+
implementation of RWT. The one that deals with AJaX-requests and JavaScript rendering output and another
+
one that delivers html markup and css as a fallback for browsers that do not support JavaScript or
+
XHttpRequests for security reasons or whatsoever. Selection of the appropriate LCAs per widget
+
and session is done transparently by the RWT-runtime.
+
 
+
The AJaX-enabled versions of the LCAs are responsible to respond only with the changes-delta
+
of the UI to client requests. This reduces network traffic immensely and enables an excellent 
+
usability.
+
 
+
 
+
===Layouts===
+
 
+
RWT reuses the original SWT layout manager implementations and therefore layouting takes
+
place on the server-side. This approach was preferred to a client side layout mechanism
+
for several reasons:
+
 
+
* AJaX enabled mode and fallback rendering mode use the same positioning mechanism for controls
+
* The programming model does not rely on knowledge of client side layouting (JavaScript), this means every application developer could introduce his own layout or reuse layouts he has written for RCP applications.
+
* the behavior of the layout algorithms are well known
+
* control bounds are already known before sending them to the server (think about on the fly diagram drawings that should fit into a certain sized rectangle)
+
 
+
 
+
===Challenges===
+
  
'''Text size calculations:'''
+
== Layouts and Text Size Determination ==
  
Despite the well working layout algorithms, it is sometimes unavoidable to do size calculations depending on a certain text. Unfortunately this can't be done on server side, only the specific client is able to determine the actual size of a text depicted using a certain font. Therefore RWT will come up with a workaround for that problem. The idea is to let the system learn about text sizes:
+
RWT reuses the original SWT layout manager implementations and therefore layouting takes place on the server-side. Despite the well working layout algorithms, it is sometimes unavoidable to do size calculations depending on a certain text. Unfortunately this can't be done on server side, only the specific client is able to determine the actual size of a text depicted using a certain font. Therefore RWT had to come up with a workaround for that problem. The idea is to let the system learn about text sizes.
 
    
 
    
 
If the system encounters an unknown text, it does a rough size calculation and sends the text to the client, where the real size is calculated. This is done with all unknown texts per request at once to avoid unnecessary traffic. The texts sent to the client have hints to controls they belong to. So the system can decide which control sizes were not accurate.
 
If the system encounters an unknown text, it does a rough size calculation and sends the text to the client, where the real size is calculated. This is done with all unknown texts per request at once to avoid unnecessary traffic. The texts sent to the client have hints to controls they belong to. So the system can decide which control sizes were not accurate.
  
The accurate text sizes are submitted via an AJaX-Request to the server, which triggers a re-layouting of the controls now using the correct sizes. The sizes are stored in a kind of map which uses a hash of text, font-family, -size and style as key. So the next time the text size is needed a simple hash-lookup provides the correct size.
+
The accurate text sizes are submitted via an AJaX-Request to the server, which triggers a re-layouting of the controls now using the correct sizes. The sizes are stored in a map which uses a hash of text, font-family, -size and style as key. The next time the text size is needed a simple hash-lookup provides the correct size.
  
To enable the system to reuse the calculated text-sizes over multiple sessions, one or multiple probe texts with known font-family, -sizes and so on are sent to the client at the beginning of each session. The hash of of the computed sizes of the texts can be used as a key for storing the map mentioned in the previous step. Simply put clients that return the same sizes for the probes are assumed to return the same sizes for texts used in the application.
+
To enable the system to reuse the calculated text-sizes over multiple sessions, probe texts with known font-family, -size and -style are sent to the client at the beginning of each session. The hash of of the computed sizes of the texts can be used as a key for storing the map mentioned in the previous step. Simply put, clients that return the same sizes for the same probes are assumed to also return the same sizes for other identical texts.
 
      
 
      
The algorithm is expected to work behind the scenes and to be transparent to the application developer. The only noticeable effect should be a little flicker of texts with unknown sizes while the recalculation takes place. This algorithm is only needed for texts where the preferred size has to be determined to layout the control – not for all texts that are displayed in the application.
+
The algorithm is working behind the scenes and is transparent to the application developer. The only noticeable effect is a little flicker of texts with unknown sizes while the recalculation takes place. This algorithm is only needed for texts where the preferred size has to be determined to layout the control – not for all texts that are displayed in the application.
  
'''Asynchronous execution of long running tasks and support of a progress bar:'''
+
== Asynchronous execution of long running tasks ==
  
Similar to SWT the RWT-UI blocks on user actions (not yet, but in the near future). Therefore only short running tasks should be executed during server-side turnarounds. Long running tasks should be running in background threads. The problem is that HTTP is a one-way request/answer protocol (the client request and get the answer) that makes it impossible for the server to inform the client about, that some background task has been finished and that the UI should be refreshed. Possible solutions are polling or the so called Comet approach.
+
Similar to SWT, the RWT-UI blocks on user actions. (In RWT its not completely bocked, but the effect is similar. Therefore only short running tasks should be executed during server-side turnarounds. Long running tasks should be running in background threads. The problem is that HTTP is a one-way request/answer protocol (the client request and get the answer). That makes it impossible for the server to inform the client that some background task has been finished and that the UI should be refreshed. The solve this problem, RAP introduced the [[RAP/UI_Callback|UI Callback]].
 
+
 
+
=== No Goes ===
+
 
+
* In contrast to SWT RWT does not support primitive graphic operations, such as line and circle drawing. RWT is restricted to the graphical capabilities of HTML-documents. JavaScript frameworks or the usage of browser plugins may alleviate this constraint in the future.
+
 
+
* RWT will not support Key-Stroke events with server-side turnarounds for event processing, since the network latency is too big to make such events usefully applicable.
+

Revision as of 17:27, 28 May 2012

Contents

Technical Overview

This document describes the technical concepts behind RAP and RWT, the RAP Widget Toolkit. RAP enables the development of Rich Internet Applications using the same programming paradigms that developers know from RCP. It consists of the following components:

  • Server side OSGi and runtime bundles (Equinox):
    One OSGi instance per web application runs in application scope. Different than RCP, RAP has to deal with user sessions. Running an OSGi instance per user-session is not feasible in a scalable way, since the memory consumption in the permanent object space would be beyond any real world resource availability. Therefore bundles are shared between user-sessions.
  • RWT (RAP Widget Toolkit):
    A Widget Library similar to SWT. RWT provides a server-side programming model for a Rich-Web-Client development. Therefore RWT uses an efficient JavaScript Widget Toolkit (a fork of Qooxdoo) that provides rich components on the client site. However, RWT-applications remain Thin Clients (opposed to Fat-Client), since all computations implemented by the application developer are done on the server-side. There is no data model on the client. The request handling is done via AJaX, which leads to a good usability and performance.
  • JFace (RAP version):
    The RAP JFace version is as closely based on the RCP Jface implementation. It provides:
    • Viewers
    • Dialogs and Wizards
    • Actions and Contributions
    • Image Registry
  • Workbench (RAP version):
    The RAP Workbench is based on the RCP Workbench implementation, but taking multi-user and memory constraints into account. It provides:
    • Workbench Windows
    • Perspectives
    • Workbench Parts
    • Selection Service

The RAP Widget Toolkit

RWT (RAP Widget Toolkit) is a GUI widget set that is as similar to SWT as possible. SWT is easy to learn, and anybody who knows SWT should have no problems to build web-front-ends using RWT. Nevertheless there are unavoidable differences between the two libraries - partially caused by the distributed nature of web applications, partially by the strengths and weaknesses of html/css, and limitations of specific browser.

To learn more about the differences between SWT and RWT from an application developer point of view, read the RAP Developers Guide. [TODO:LINK!]

At runtime, all RWT widgets consist of a server-side Java object, and a client-side JavaScript object presented to the user in HTML/CSS. The application code only interacts with the Java instance, while the user only interacts with the client instance. Like SWT, RWT provides an event model to enable the application programmer to react on user actions like pushing a button. This is different to SWT, as the action has to be submitted to the server, where a action handler will be executed. The communication with the server is done by an AJaX-Request. Beyond the distributed nature of event processing, RWT has to synchronize the widgets client state and server state. This needs to be performed before and after action handlers are executed.

LifeCycle

To meet this requirements RWT divides a http-request into different phases that are executed sequentially. Each phase has its special purpose and creates the prerequisites needed by the following phases for proper execution. The control mechanism behind this is the RWTLifeCycle. Note that most of the time an application developer do not have to care about the lifecycle phases, since they work behind the scenes. The lifecycle phases are named Prepare UI Root,Read Data,Process Action and Render.

  • Prepare UI Root: Currently responsible for invoking entry points. Implementations of IEntryPoint represent the UI creation entry points (these take over the functionality of a main function used to start a SWT-applictations).
  • Read Data: Request parameters that contain status information belonging to certain Widgets will be applied to those widgets. If an user has entered some characters into an input-type text field that represents a server-side Text control, these characters are transmitted to the text-attribute of the Text instance in this phase.
  • Process Action: This is the phase where the requested user-action takes place. User actions are triggered for example by clicking a push-button. Application programmers implement and register listeners at the corresponding widget (e.g. a SelectionListener for a Button), to react to such events.
  • Render: This is when the javascript code (as of RAP 1.5, JSON) is created, which will be sent to the browser. During the actual rendering no changes of the widget-tree will happen - neither creation or addition of new widgets nor changing of attributes of existing ones. The AJaX-rendering-mode only creates assignments of those widget-attributes that were changed during the request-processing. This results in a minimal amount of information that needs to be exchanged between server and client.

Widgets

Considering the already said, RWT-Widgets must meet the following objective: They have to provide a well known API but deal transparently with the lifecycle mechanism. To achieve this the RWT-Runtime creates adapters for each widget. Therefore each widget is composed of three server-side parts at runtime:

  • The widget instance, contains status information set by the programmer via the widget's API.
  • A widget adapter instance, contains additional status information used by the runtime (e.g. information needed to decide whether a widget attribute has changed during the request processing and whether the new value must be sent to the client or not)
  • A shared instance of an lifecycle adapter. Each widget type has an own type of LCA. The LCA is a stateless callback handler used by the RWTLifeCycle to synchronize the widgets state with the client changes, call events etc.

Layouts and Text Size Determination

RWT reuses the original SWT layout manager implementations and therefore layouting takes place on the server-side. Despite the well working layout algorithms, it is sometimes unavoidable to do size calculations depending on a certain text. Unfortunately this can't be done on server side, only the specific client is able to determine the actual size of a text depicted using a certain font. Therefore RWT had to come up with a workaround for that problem. The idea is to let the system learn about text sizes.

If the system encounters an unknown text, it does a rough size calculation and sends the text to the client, where the real size is calculated. This is done with all unknown texts per request at once to avoid unnecessary traffic. The texts sent to the client have hints to controls they belong to. So the system can decide which control sizes were not accurate.

The accurate text sizes are submitted via an AJaX-Request to the server, which triggers a re-layouting of the controls now using the correct sizes. The sizes are stored in a map which uses a hash of text, font-family, -size and style as key. The next time the text size is needed a simple hash-lookup provides the correct size.

To enable the system to reuse the calculated text-sizes over multiple sessions, probe texts with known font-family, -size and -style are sent to the client at the beginning of each session. The hash of of the computed sizes of the texts can be used as a key for storing the map mentioned in the previous step. Simply put, clients that return the same sizes for the same probes are assumed to also return the same sizes for other identical texts.

The algorithm is working behind the scenes and is transparent to the application developer. The only noticeable effect is a little flicker of texts with unknown sizes while the recalculation takes place. This algorithm is only needed for texts where the preferred size has to be determined to layout the control – not for all texts that are displayed in the application.

Asynchronous execution of long running tasks

Similar to SWT, the RWT-UI blocks on user actions. (In RWT its not completely bocked, but the effect is similar. Therefore only short running tasks should be executed during server-side turnarounds. Long running tasks should be running in background threads. The problem is that HTTP is a one-way request/answer protocol (the client request and get the answer). That makes it impossible for the server to inform the client that some background task has been finished and that the UI should be refreshed. The solve this problem, RAP introduced the UI Callback.