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.
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
→ 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 – takes long time to get familiar with RCP … (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
→ 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 → 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
→ 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
→ 2 workspaces, one for each target
shared projects referenced by both workspaces
→ 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
‘Optional’
‘Reexport this dependency’
First error:
binding extension point not available in RAP
same problem as API differences applies also to extension points:
- missing: e.g. bindings, helpSupport …
- additional E-Ps for web specific requirements
e.g. entrypoint, phaselistener …
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 → 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 …
… 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