Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "E4/position papers/Christian Campo"
| Line 8: | Line 8: | ||
=== Development of plugins === | === Development of plugins === | ||
| + | ==== consolidate remove duplicates ==== | ||
I see a strong need to improve the API (as others have expressed). Can we start to remove duplicate and triple implementations of the same thing ? Preferences is the best example of that but there are others. Can we have some best practise, rules of which is the "right" implementation ? And most important, can we deprecate all the others and have a plan by when deprecatation will lead to removal ? | I see a strong need to improve the API (as others have expressed). Can we start to remove duplicate and triple implementations of the same thing ? Preferences is the best example of that but there are others. Can we have some best practise, rules of which is the "right" implementation ? And most important, can we deprecate all the others and have a plan by when deprecatation will lead to removal ? | ||
| + | ==== services and extensions ==== | ||
Use more OSGi Services instead of Singletons. Synchronize the way we use (=API) extensions and services. Currently everyone seems to have a strong opinion that one is better than the other. I think Extensions can and should be mapped to Java Objects so that they can be injected into any component without deeper knowledge about the platform. Once you have injection for extensions its is only a small difference whether you inject a service or an extension. | Use more OSGi Services instead of Singletons. Synchronize the way we use (=API) extensions and services. Currently everyone seems to have a strong opinion that one is better than the other. I think Extensions can and should be mapped to Java Objects so that they can be injected into any component without deeper knowledge about the platform. Once you have injection for extensions its is only a small difference whether you inject a service or an extension. | ||
i.e. | i.e. | ||
| Line 18: | Line 20: | ||
That allows us to free business code from container dependant code. So business components get things inject and dont have to deal with container specific accessors. Ease testing and so on. | That allows us to free business code from container dependant code. So business components get things inject and dont have to deal with container specific accessors. Ease testing and so on. | ||
| + | === client/server split === | ||
| + | * consider that components can lie on different sides depending on the scenario | ||
| + | ** RAP/WTP versus RCP versus Client Server models like Riena | ||
| + | ** platform support for having that single session (client) versus multisession/multiserver context (server) | ||
| + | ** decouple components so that its gets easier to move them | ||
| − | + | === we can do better on the serverside when running in a WAR === | |
| − | + | While running OSGi in the embedded Jetty is great and easy, the support for WAR deployment isnt equally strong: | |
| − | + | * build war from product | |
| − | + | * Tomcat plugin to run OSGi as WAR within Eclipse | |
| + | * embedded webapps run as root webapp context while WAR webapps mostly have a name | ||
| − | + | === alternate UI === | |
| − | + | * RCP UI looks like the IDE | |
| − | + | * is not that easy on endusers | |
| − | + | * while there is an option to allow "freestyle" there is certain of look that seems well established i.e. Outlook, CAETeam and others (including Riena) | |
| − | + | some samples: | |
| − | + | ||
| − | + | ||
| − | + | ||
Revision as of 16:35, 20 May 2008
Contents
Position Paper: Christian Campo
There a number of topics that I'd like to be addressed in E4 that are driven by the Riena requirements in the following areas
- Development of plugins
- client/server split
- Serverside Eclipse
- Different UI
Development of plugins
consolidate remove duplicates
I see a strong need to improve the API (as others have expressed). Can we start to remove duplicate and triple implementations of the same thing ? Preferences is the best example of that but there are others. Can we have some best practise, rules of which is the "right" implementation ? And most important, can we deprecate all the others and have a plan by when deprecatation will lead to removal ?
services and extensions
Use more OSGi Services instead of Singletons. Synchronize the way we use (=API) extensions and services. Currently everyone seems to have a strong opinion that one is better than the other. I think Extensions can and should be mapped to Java Objects so that they can be injected into any component without deeper knowledge about the platform. Once you have injection for extensions its is only a small difference whether you inject a service or an extension. i.e. Inject.service("FooService").into(myComponent).andStart(context); // inject instance of service Inject.extension("extpoint").useType(IData.class).into(myComponent).andStart(contenxt); // inject instances of extensions @see http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions
That allows us to free business code from container dependant code. So business components get things inject and dont have to deal with container specific accessors. Ease testing and so on.
client/server split
- consider that components can lie on different sides depending on the scenario
- RAP/WTP versus RCP versus Client Server models like Riena
- platform support for having that single session (client) versus multisession/multiserver context (server)
- decouple components so that its gets easier to move them
we can do better on the serverside when running in a WAR
While running OSGi in the embedded Jetty is great and easy, the support for WAR deployment isnt equally strong:
- build war from product
- Tomcat plugin to run OSGi as WAR within Eclipse
- embedded webapps run as root webapp context while WAR webapps mostly have a name
alternate UI
- RCP UI looks like the IDE
- is not that easy on endusers
- while there is an option to allow "freestyle" there is certain of look that seems well established i.e. Outlook, CAETeam and others (including Riena)
some samples: