Single Sourcing RCP and RAP

The Rich Ajax Platform (RAP) provides a framework and set of tools to develop rich clients and web clients from a single code base (single sourcing), either from scratch or by migrating an existing Rich Client Platform (RCP) application. In this talk we'll explore the differences between RAP and RCP that are especially relevant to the goal of single sourcing as much code as possible. Attendees will learn about the benefits of single sourcing and get a live demo of a single sourced application.

No notes for slide

introducing each other
EclipseSource

Problems:
* existing RCP Code
* RCP developers not familiar with web technologies

* Example: insurance business, complicated forms
* Reuse code
* Reuse knowledge
* Same development environment (Eclipse)
* Same concepts (Plug-ins, Extension Points)

* Single sourcing is dev of web and desktop apps from a single code base

OSGi specifies a dynamic component model:
the Eclipse OSGi implementation is provided by the Equinox project

RAP consists of bundles
RAP runs on OSGi

Overview of RCP Layers
SWT building blocks, native widgets
JFace add higher-level API for common UI tasks
Workbench does presentation and coordination of UI

need to replace SWT with sth.

RWT implements same API as SWT
- client and server part
- uses qooxdoo on client
- server build on Equinox
- server based on JEE techn.
- runs in a servlet container (servlet 2.3 - 2.5)
- subsets of SWT, JFace, Workbench APIs

SWT, JFace, Workbench APIs
&#x2192; same UI concepts

XXX: exchange text RWT ~ SWT

Same UI concepts as in RCP
But might not always fit for a web app

Same building blocks, can be arranged differently

examples:
- custom perspective switcher
- custom menu

reuse of existing RCP code
* 80% - 98%

also reuse of knowledge &#x2013; takes long time to get familiar with RCP &#x2026; (cobbler, stay with your trade)

Why not 100%?
* RAP provides only a subset of RCP
* applications need to become multi-user enabled

This talk is about how to deal with the gray part

Restrictions due to web environment:

unsupported RCP API
- GC (research) no platform-indep. perfomant drawing
- MouseMove

slightly different
- modify events sends data in chunks
- file upload

web-specific requirements
- theming

RAP is client/server
RAP runs in a multi-user environment
- one OSGi instance for all sessions in RAP
&#x2192; shared bundles
- singletons shared between sessions
- no implicit thread to session assignment
- resources (images, colors und fonts) are shared
Different scopes

Result multi-user + browser &#x2192; different code
need to separate shared and specific code
need place to put the differences

possiblities?

- plug-ins, extension points
- services
- fragments

RCP development against RCP runtime

RAP runtime

&#x2192; 2 targets

RAP and RCP need different targets

switching a target is time-consuming because the complete workspace is recompiled

avoids need to open and close projects

&#x2192; 2 workspaces, one for each target

shared projects referenced by both workspaces
&#x2192; not include projects in workspace folder

In the RCP Workspace
Created by using new plug-in project wizard
Filed in a common projects folder
Created as Rich Client Application

runs immediately

Create RAP workspace / switch

do not copy projects into workspace

after import 216 error markers
step by step conversion to support both runtimes
First problem: dependencies

problem of different bundle ids

possible solutions:

package import
OSGi specification section 3.13.2
problems caused by split-packages

optional dependencies on both
warnings caused by missing bundle references
reexport

list of required bundles
org.eclipse.rap.ui
org.eclipse.ui

properties
&#x2018;Optional&#x2019;
&#x2018;Reexport this dependency&#x2019;

First error:

binding extension point not available in RAP

same problem as API differences applies also to extension points:
- missing: e.g. bindings, helpSupport &#x2026;
- additional E-Ps for web specific requirements
e.g. entrypoint, phaselistener &#x2026;

need place to put platform specific parts

Fragments are bundles that are merged with a host at runtime
- can contribute extensions
- same classloader as host
- at runtime, it's like one bundle

well suited to solve single sourcing problems

* two fragments per plug-in
one for RAP specifics
one for RCP specifics

* at runtime, only the plug-in that fits the
environment will be installed

using the new project wizard
fragment project
all fragments are filed in the projects folder
each workspace contains only the
relevant fragments

in RCP workspace

move extension from plugin.xml &#x2192; fragment.xml

solution:
delegation-like pattern

abstract supertype in host-bundle, that encapsulates the problem

type implementation in the (platform dependent) fragment solves the problem

loading the platform specific implementation at runtime by means of reflection

RCP has ActionFactory.ABOUT

not available in RAP

use custom AboutAction

use delegation to cover differences
(same code for both platforms)

static initializer: loads impl

create delegates to impl

createInternal does the actual work

finds impl by naming convention

needs reflection
because no reference to impl at compile time

All errors resolved &#x2026;

&#x2026; now how to RUN it?

entry point
main method in SWT
entry point is counterpart to main method

extension point

attr:
parameter (URL parameter)
class (implements interface)

the recommended way to work with different targets

excursion:

hides optional decencies from app bundles

reexport!

location in projects folder

import into both workspaces