Difference between revisions of "Riena/RAP Support"
|Line 10:||Line 10:|
== Getting Started ==
== Getting Started ==
See [http://.eclipse.org///org.eclipse.riena/org.eclipse.riena.releng.rap/readme.txt readme.txt] in org.eclipse.riena.releng.rap for the most current information.
== Known Issues ==
== Known Issues ==
Revision as of 08:21, 29 June 2012
This page is a whiteboard with information about running Riena on RAP and known issues.
See readme.txt in org.eclipse.riena.releng.rap for the most current information.
This is ongoing work. Expect more issues to be added.
- [ui] Error Marker decoration does not show
- [ui] Splash Dialog is not supported in RAP - affects riena login mechanism
- [ui] Custom text ridgets (numeric, decimal, date) don't work because of differences in event handling
- [ui] CompletionCombo - icon for drop-down button missing
- [rap] No support for keyboard shortcuts / mnemonics
Fixed Issues (on HEAD branch)
- [ui] SWT UI Synchronizer is broken - likely fix: receive an external display reference at construction time
- [ui] Dialog based classes (RienaMessageDialog, UIProcessWindow) don't work - their renderer needs single-sourcing
- [ui] DatePicker - icon on 'picker' button missing
- [navi] Navigation model does not support multiple users (singleton)
- [navi] Submodules (i.e. tree element) sometimes need two clicks before the corresponding view is shown
- [ui] Playground - Link/Browser demo - link needs two clicks before browser is updated
- [ui] InfoFlyout - need RAP specific implementation (also: discuss animations in RAP team)
- [rap] Widget traversal by hitting TAB
While porting Riena to RAP we encounter several issues (some say challenges). Most (or probably all) of these issues are well known and RAP has already solutions for them - see FAQs.
The goals for the port are:
- do not place a burden to the users of Riena
- the impact (of this port) should not harm (efficency, code bloat, ..) Riena when used in a RCP fashion
The following sections describe concrete problems and patterns how to solve them.
Platform specific implementations
Although RAP handles a lot of SWT's funtionality for the web, there is functionality that it does not (yet) handle. For these cases Elias introduced the facade factory pattern. (The following description is picked from a mail to riena-dev)
The facade factory only works because of some careful bundle/classpath engineering. It is crafted for one particular use, i.e picking between RAP/RCP.
Here are the prerequisites:
- three bundles are necessary. Two of them have different dependencies (swt vs rwt)
- facadeFactory and the facade implementations are in the same package in all three bundles
- the .swt.rap and swt.rcp bundles are buddies to o.e.r.ui.swt so that the FacadeFactory has access to their classpaths and can instantiante classes from the common package.
- there is a naming convention <FacadeName>RAP <FacadeName>RCP
There are two kinds of singletons within Riena
- Class.getInstance() based singletons (based on a static getInstance() method), e.g. NavigationNodeProvider
- Class.staticMethods() based singletons (based on static methods and static fields, i.e there is some state), e.g. ApplicationNodeManager
Note: Classes with only static methods and no static fields are not singletons
To solve the singleton problem within RAP it provides the (abstract) SessionSingletonBase class that is able to create session-dependent singletons. This class may be used directly by calling it's (static) getInstance(Class type) method or by sub-classing and providing a taylored (static) getInstance() method. With this it is very easy to transform the first singleton type and a little bit more work to transform the second type - both without breaking the current interface of course.
The straightforward technique of just passing a class to the getInstance() method is for most cases sufficent. However, it does not allow to:
- use constructors with parameters
- it is not possible to "wire" the singleton (wiring is the term we use for Riena's dependency injection)
Of course, it possible to create workarounds:
- use setters instead of constructor parameters - may result in undesired usage
- do the wiring within the constructor - makes e.g. unit testing more complicated
The introduction of e.g. an IInstanceFactory interface with a single getInstance() method could solve this. The class implementing the IInstanceFactory could then internally be used for creating the key to store the singleton in the session store. And the usage of generics would be a nice bonus.
A OSGi Service is also some kind of singleton, i.e. it exists only once in a JVM. How to deal with services that have (session dependent) state?
This is just a reminder! Are ThreadLocals safe?
This is just a reminder! This utility tells whether it is running on a client or a server. This allows to implement common code that behaves differently on client or server. We have to think about that!