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] Dialog based classes (RienaMessageDialog, UIProcessWindow) don't work - their renderer needs single-sourcing
- [ui] DatePicker - icon on 'picker' button missing
- [ui] CompletionCombo - icon for drop-down button missing
- [ui] InfoFlyout - need RAP specific implementation (also: discuss animations in RAP team)
- [ui] Playground - Link/Browser demo - link needs two clicks before browser is updated
- [ui] SWT UI Synchronizer is broken - likely fix: receive an external display reference at construction time
- [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
- [rap] No support for keyboard shortcuts / mnemonics
- [rap] Widget traversal by hitting TAB
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), e.g. ApplicationNodeManager
Two 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. The straightforward technique of just passing a class to the getInstance() method is for most cases sufficent. However, it does not allow to:
- use constructores with parameters
- it is not possible to "wire" the singleton
Of course, it possible to create workarounds:
- use setters instead of constructor paramters - 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 IInstanceFactory could then internally be used for creating the key to store the singleton in the session store.