Single Sourcing RCP and RAP

  • 5,579 views
Uploaded on

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 …

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.

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,579
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
1
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    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
    → 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

Transcript

  • 1. Single-Sourcing RAP and RCP Chris Aniszczyk zx@eclipsesource.com
  • 2. Leadership roles in over 10 Eclipse projects Equinox, OSGi, RCP, p2, RAP, PDE, ECF, ... Provide services and solutions for the Eclipse ecosystem 2
  • 3. What is Eclipse? 3
  • 4. Eclipse is a Technology! 4
  • 5. 5
  • 6. Eclipse is a Foundation! 6
  • 7. 7
  • 8. Eclipse is a Ecosystem! 8
  • 9. Let’s Talk Technology...
  • 10. RCP! 11
  • 11. Lotus Notes 8+ 12
  • 12. Lotus Sametime 7.5+ 13
  • 13. NASA 14
  • 14. RCP Knowledge
  • 15. Web 2.0 16
  • 16. Online Presentations? 17
  • 17. Online Photoshop? 18
  • 18. Pixlr 19
  • 19. Web 2.0 Knowledge 20
  • 20. 21
  • 21. Web 2.0 Desktop
  • 22. 23
  • 23. 24
  • 24. 25
  • 25. Impossible? 26
  • 26. Exchange the Runtime! 27
  • 27. Foundation: OSGi RCP RAP equinox 28
  • 28. Layers of RCP
  • 29. RAP Layers
  • 30. On the Surface
  • 31. Best of both worlds 33
  • 32. Select a point of view 34
  • 33. Why!? 35
  • 34. It’s possible! 36
  • 35. 37
  • 36. 38
  • 37. How much reuse!? 39
  • 38. Code Reuse 80%–98% is possible platform specific code shared code 40
  • 39. What about the 2-20%? 41
  • 40. RAP Runs in a Browser File system File upload GraphicsContext RCP RAP
  • 41. RAP is Multi-User! RCP RAP
  • 42. API Differences RCP RAP Desktop-only Web-specific features features
  • 43. Handy Tools Eclipse SDK RAP SDK includes - RAP Runtime - Tooling - Help
  • 44. Workplace
  • 45. Shared Projects RAP Workspace RCP Workspace
  • 46. Example Application RCP Mail Demo 49
  • 47. Runs immediately 50
  • 48. Lift Off 51
  • 49. Conclusion Thanks for listening! Questions!? www.eclipsesource.com www.eclipse.org/rap 52
  • 50. Extra Slides... 53
  • 51. Import into RAP Workspace 54
  • 52. Do not copy! 55
  • 53. Don't Panic! 56
  • 54. Dependencies Package Imports Optional Dependencies 57
  • 55. Optional Dependencies 58
  • 56. 59
  • 57. Fragments Fragments Host Bundle
  • 58. Create Fragments maildemo.rap maildemo.rcp 61
  • 59. Move extensions 62
  • 60. 63
  • 61. Delegation Bundle Fragment 64
  • 62. API Differences RCP RAP RCP + RAP 65
  • 63. Helper Class 66
  • 64. ImplementationLoader 67
  • 65. Implementations RCP RAP 68
  • 66. Zero Errors 69
  • 67. Entry Point 70
  • 68. Summary 71
  • 69. Use Two Workspaces 72
  • 70. Optional Dependencies 73
  • 71. Compatibility Plug-in
  • 72. Use Fragments Fragments Host Bundle
  • 73. Use Delegation Bundle Fragment 76