Single Sourcing RCP and RAP
•
7 gefällt mir•4,283 views
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.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Single Sourcing RCP and RAP
Ähnlich wie Single Sourcing RCP and RAP (20)
Mehr von Chris Aniszczyk
Mehr von Chris Aniszczyk (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Single Sourcing RCP and RAP
- 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
- 5. 5
- 7. 7
- 11. RCP! 11
- 12. Lotus Notes 8+ 12
- 13. Lotus Sametime 7.5+ 13
- 14. NASA 14
- 15. RCP Knowledge
- 16. Web 2.0 16
- 17. Online Presentations? 17
- 18. Online Photoshop? 18
- 19. Pixlr 19
- 20. Web 2.0 Knowledge 20
- 21. 21
- 22. Web 2.0 Desktop
- 23. 23
- 24. 24
- 25. 25
- 26. Impossible? 26
- 27. Exchange the Runtime! 27
- 28. Foundation: OSGi RCP RAP equinox 28
- 29. Layers of RCP
- 31. RAP Layers
- 32. On the Surface
- 33. Best of both worlds 33
- 34. Select a point of view 34
- 35. Why!? 35
- 36. It’s possible! 36
- 37. 37
- 38. 38
- 39. How much reuse!? 39
- 40. Code Reuse 80%–98% is possible platform specific code shared code 40
- 41. What about the 2-20%? 41
- 42. RAP Runs in a Browser File system File upload GraphicsContext RCP RAP
- 43. RAP is Multi-User! RCP RAP
- 44. API Differences RCP RAP Desktop-only Web-specific features features
- 46. Handy Tools Eclipse SDK RAP SDK includes - RAP Runtime - Tooling - Help
- 47. Workplace
- 48. Shared Projects RAP Workspace RCP Workspace
- 49. Example Application RCP Mail Demo 49
- 50. Runs immediately 50
- 51. Lift Off 51
- 52. Conclusion Thanks for listening! Questions!? www.eclipsesource.com www.eclipse.org/rap 52
- 53. Extra Slides... 53
- 54. Import into RAP Workspace 54
- 55. Do not copy! 55
- 56. Don't Panic! 56
- 57. Dependencies Package Imports Optional Dependencies 57
- 58. Optional Dependencies 58
- 59. 59
- 60. Fragments Fragments Host Bundle
- 61. Create Fragments maildemo.rap maildemo.rcp 61
- 62. Move extensions 62
- 63. 63
- 64. Delegation Bundle Fragment 64
- 66. Helper Class 66
- 67. ImplementationLoader 67
- 68. Implementations RCP RAP 68
- 69. Zero Errors 69
- 70. Entry Point 70
- 71. Summary 71
- 72. Use Two Workspaces 72
- 73. Optional Dependencies 73
- 75. Use Fragments Fragments Host Bundle
- 76. Use Delegation Bundle Fragment 76
Hinweis der Redaktion
- 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