Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "E4/position papers/Christian Campo"

< E4
(alternate UI)
(services and extensions)
 
(3 intermediate revisions by one other user not shown)
Line 12: Line 12:
  
 
==== services and extensions ====
 
==== 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.  
i.e.
+
* Synchronize the way we use (=API)  extensions and services.
Inject.service("FooService").into(myComponent).andStart(context); // inject instance of service
+
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.
Inject.extension("extpoint").useType(IData.class).into(myComponent).andStart(context); // inject instances of extensions
+
i.e.<br/>
 +
<b>Inject.service("FooService").into(myComponent).andStart(context);</b> // inject instance of service
 +
<b>Inject.extension("extpoint").useType(IData.class).into(myComponent).andStart(context);</b> // inject instances of extensions
 
@see http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions
 
@see http://wiki.eclipse.org/Riena_Getting_Started_with_injecting_services_and_extensions
  
Line 35: Line 37:
 
* RCP UI looks like the IDE
 
* RCP UI looks like the IDE
 
* is not that easy on endusers
 
* 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)
+
* while there is an option to allow "freestyle" there is certain of look that seems well established i.e. Outlook and others (including Riena)
 +
* there is already some common sense how user interfaces for endusers are designed like MS Office, Lotus etc.
 +
* wouldn't it be cool that we have more support for that in Eclipse rather than each application has to build that from scratch.
 +
* endusers no longer expect their tools to have a native platform look
  
 
some samples:
 
some samples:
  
[[Image:Riena1-small.jpg]]
+
[[Image:Riena1-small.jpg]] [[Image:Riena-E4-outlook-small.jpg]]
  
 
=== Bio ===
 
=== Bio ===
 
Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.
 
Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.

Latest revision as of 23:18, 21 May 2008

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(context); // 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

improve serverside equinox 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 and others (including Riena)
  • there is already some common sense how user interfaces for endusers are designed like MS Office, Lotus etc.
  • wouldn't it be cool that we have more support for that in Eclipse rather than each application has to build that from scratch.
  • endusers no longer expect their tools to have a native platform look

some samples:

Riena1-small.jpg Riena-E4-outlook-small.jpg

Bio

Christian Campo is Software Developer at compeople AG. He is project lead of Riena, an Eclipse project that is currently in Incubator phase. http://www.eclipse.org/Riena.

Back to the top