Skip to main content
Jump to: navigation, search

Difference between revisions of "E4/Eclipse Application Services"

< E4
(Change the list into a table.)
Line 10: Line 10:
 
There has been a discussion about if this list is too large. The conclusion is that you can build applications with subsets, but bigger applications usually need most of them. Instead of reducing the list further we want to make sure that in future there is only exactly one way to do a thing, not multiple as it is today.
 
There has been a discussion about if this list is too large. The conclusion is that you can build applications with subsets, but bigger applications usually need most of them. Instead of reducing the list further we want to make sure that in future there is only exactly one way to do a thing, not multiple as it is today.
  
−
=== Fundamentals ===
+
= Application Services =
−
* [[E4/EAS/Life Cycle|Life Cycle]] - initialization and disposal.
+
==Core==
−
* [[Image:Glass.gif]] [[E4/EAS/Authentication|Authentication]] (single sign on)
+
{| border="1" cellpadding="2" width="100%"
−
* [[Image:Progress.gif]] [[E4/EAS/Status Handling|Status Handling]] (errors and warnings).
+
!width="15%"|Name
−
* [[E4/EAS/Logging|Logging]] over and above status handling.
+
!width="30%"|Description
−
* [[E4/EAS/Extension Registry|Extension Registry]]. Registering and accessing extensions and extension points. (Eclipse 3.x: IExtensionRegistry)
+
!width="5%"|Priority
−
* [[E4/EAS/Scheduling Background Work|Scheduling Background Work]]. Schedule work in a way that is visible to the user. (Eclipse 3.x: IProgressService)
+
!width="25%"|Status
−
* Accessing [[E4/EAS/Preferences|Preferences]] (mostly read access, but sometimes write access). (Eclipse 3.x: IPreferencesService)
+
|-
−
* [[Image:Progress.gif]] [[E4/EAS/Reporting Status|Reporting Status]] (think status line).
+
| [[E4/EAS/Life Cycle|Life Cycle]]
−
* [[E4/EAS/String Localization|String Localization]].
+
| A defined path of initialization and disposal for components.
−
* [[E4/EAS/Adapting Objects|Adapting Objects]]. Adapt an object (typically, the current selection) to a type that is relevant to the current plug-in. (Eclipse 3.x: IAdapterManager)
+
| High
 +
| [[Image:Progress.gif]] Use JSR-250 annotations (@PostConstruct/@PreDestroy) for Java case. Not clear how to advance on JS side.
 +
|-
 +
| [[E4/EAS/Authentication|Authentication/Single Sign-on]]
 +
| A component should be able to request authentication in a way that the end user perceives as consistent. Different backends can have different requirements, will need to support multiple mechanisms.
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|-
 +
| [[E4/EAS/Status Handling|Status Handling]]
 +
| Need a consistent way for components to report warnings / unexpected errors.
 +
| High
 +
| [[Image:Glass.gif]] Clients should be able to use DI to inject a status handler for handling statuses, see org.eclipse.e4.core.services.IStatusHandler.
 +
|-
 +
| Logging/Tracing
 +
| Components should be able to easily access a logger or provide tracing mechanisms to help with debugging.
 +
| High
 +
| [[Image:Error.gif]] Clients should be able to use DI to inject a logger/tracer, see org.eclipse.e4.core.services.Logger. Note that there is also the OSGi LogService.
 +
|-
 +
| Extension Registry
 +
| Registering and accessing extensions and extension points.
 +
| High
 +
| [[Image:Question.gif]] 3.x version would be IExtensionRegistry, does this need to be updated?
 +
|-
 +
| Scheduling Work/Reporting Progress
 +
| A component should be able to schedule work in the foreground or in the background.
 +
| High
 +
| [[Image:Error.gif]] 3.x variant is IProgressService, IRunnableWithProgress, and Jobs framework.
 +
|-
 +
| [[E4/EAS/Preferences|Reading/Writing of Preferences]]
 +
| A component should be able to schedule work in the foreground or in the background.
 +
| High
 +
| [[Image:Glass.gif]] Lots of existing preferences stories in 3.x, very confusing to API consumers.
 +
|-
 +
| Reporting Status
 +
| Users should be able to easily check the status of operations/requests. In 3.x this is done in the status line and the 'Progress' view.
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|-
 +
| String Localization
 +
| The Eclipse Platform needs to ensure that localization can easily be done by product teams.
 +
| High
 +
| [[Image:Error.gif]] No progress. See {{bug|226340}} and {{bug|244468}} for more information.
 +
|-
 +
| Adapting Objects
 +
| The adapter pattern should be supported.
 +
| High
 +
| [[Image:Question.gif]] 3.x version would be IAdapterManager, does this need to be updated?
 +
|-
 +
| Commands/Handlers
 +
| Clients should be able to register handles for global commands like cut/copy/paste.
 +
| High
 +
| [[Image:Progress.gif]] 3.x version would be ICommandService, IHandlerService, etc. e4 will have ECommandService, EHandlerService, and others.
 +
|-
 +
| Eventing System
 +
| Clients should be able to monitor events easily without having a myriad of different kinds of listeners.
 +
| High
 +
| [[Image:Progress.gif]] See {{bug|288999}}.
 +
|}
  
−
=== Specific to UI Parts ===
+
== User Interface ==
−
* [[Image:Glass.gif]] [[E4/EAS/Receiving Input|Receiving Input]].
+
{| border="1" cellpadding="2" width="100%"
−
* [[Image:Glass.gif]] [[E4/EAS/Producing Selection|Producing Selection]]. (Eclipse 3.x: ISelectionService)
+
!width="15%"|Name
−
* [[E4/EAS/Persisting Data|Persisting Data]]. Receiving persisted state, and producing persistable state (typically UI state), such as e.g. layouts, dialog sizes, viewer selection and expansion state.  (Eclipse 3.x: IDialogSettings, IMemento)
+
!width="30%"|Description
−
* [[E4/EAS/Managing Shared Resources|Managing Shared Resources]] (e.g. JFace LocalResourceManager).
+
!width="5%"|Priority
−
* [[E4/EAS/Help|Help]]. Connecting to the help system so that help affordances can be shown that open context-sensitive help. (Eclipse 3.x: IWorkbenchHelpSystem)
+
!width="25%"|Status
−
* Participating in [[E4/EAS/Undo Redo|Undo/Redo]]. (Eclipse 3.x: IWorkbenchOperationSupport)
+
|-
−
* [[Image:Progress.gif]] Participating in [[E4/EAS/Editor Lifecycle|Editor Lifecycle]] (units of saveability, dirtiness, saving, prompting to save).
+
| Receiving Input
−
* [[E4/EAS/Updating UI Elements|Updating UI Elements]] such as e.g. enablement, labels, icons of menu and tool items.
+
| Model objects (parts?) should be able to define an input.
−
* Registering handlers for [[E4/EAS/Commands|Commands]]. For example, handling global commands like Copy and Paste. (Eclipse 3.x: IHandlerService)
+
| High
−
* [[E4/EAS/Notifications|Notifications]]. Inform the user of events in the application that may require attention, whether or not the application is visible.
+
| [[Image:Progress.gif]] DI can be used in this case. Currently the model would define 'input' as a variable that is modifiable by an IEclipseContext.
 +
|-
 +
| Providing Selection Information
 +
| Different parts of the model should be able to react to current active selection of other parts.
 +
| High
 +
| [[Image:Progress.gif]] DI can be used in this case. Currently the model would define 'selection' as a variable that is modifiable by an IEclipseContext. In 3.x there is ISelectionService.
 +
|-
 +
| Persisting State and Data
 +
| The user interface must be able to remember things like its size and layouts when it has been recreated.
 +
| High
 +
| [[Image:Error.gif]] In 3.x, IDialogSettings and IMemento is used.
 +
|-
 +
| Managing Shared Resources
 +
| There should be a mechanism to pool identical resources together and share them to keep memory footprint low.
 +
| High
 +
| [[Image:Error.gif]] 3.x version would be JFace's AbstractResourceManager and friends.
 +
|-
 +
| Participating in Undo/Redo Support
 +
| Clients should be able to push operations to the undo/redo service and have it be tie in with other operations on the stack automatically.
 +
| High
 +
| [[Image:Error.gif]] 3.x version would be IWorkbenchOperationSupport.
 +
|-
 +
| Participating in Editor/Saveable Part Life Cycle
 +
| Management of dirty state, save management, prompting to save unsaved resources, etc.
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|-
 +
| Updating UI Elements
 +
| Components should be able to modify model objects directly and the UI should update if necessary
 +
| High
 +
| [[Image:Error.gif]] No progress. Tie in with 3.x databinding APIs?
 +
|-
 +
| [[E4/EAS/Notifications|Notifications]]
 +
| Inform the user of events in the application that may require attention, regardless of whether the application is visible or not.
 +
| High
 +
| [[Image:Error.gif]] No progress. See [[Platform UI/Notifications]] for ideas.
 +
|}
  
−
=== Specific to Command Handlers ===
+
== Advanced ==
−
* [[Image:Glass.gif]] [[E4/EAS/Reporting Progress|Reporting Progress]] including responding to cancellation requests.
+
{| border="1" cellpadding="2" width="100%"
 +
!width="15%"|Name
 +
!width="30%"|Description
 +
!width="5%"|Priority
 +
!width="25%"|Status
 +
|-
 +
| Shell Provider
 +
| Dialogs/Windows need to be parented off of the proper window.
 +
| High
 +
| [[Image:Error.gif]] In 3.x there is JFace's IShellProvider interface. Also see {{bug|231150}}.
 +
|-
 +
| Reacting [[E4/Workbench Model|Workbench Model]] Changes.
 +
| Clients should be able to listen for changes in the workbench model.
 +
| High
 +
| [[Image:Progress.gif]] See IEventBroker.
 +
|-
 +
| Participating in Label and Icon Decoration
 +
| The user interface must be able to remember things like its size and layouts when it has been recreated.
 +
| High
 +
| [[Image:Error.gif]] In 3.x, there is the IDecoratorManager and an extension point for contributing decorators.
 +
|-
 +
| Reacting to Changes to the Context
 +
| The Eclipse Platform needs to be able to react to bundles coming and going on-the-fly at runtime.
 +
| High
 +
| [[Image:Error.gif]] 3.x version would be the IExtensionTracker.
 +
|-
 +
| Dynamically Contributing to the [[E4/Workbench Model|Workbench Model]]
 +
| Clients should be able to add tool items, menus, parts, and other such model objects to the workbench.
 +
| High
 +
| [[Image:Progress.gif]] Extension point is under development.
 +
|-
 +
| Object Contributions
 +
| Actions that can be contributed to objects of a certain type.
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|-
 +
| [[E4/EAS/Focus Service|Focus Service]]
 +
| It should be possible to drive and enhance the presentation of the model/workbench based on the current "focus".
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|}
  
−
=== Advanced ===
+
== Domain-Specific ==
−
* [[E4/EAS/Shell Provider|Shell Provider]] (for properly parenting dialogs).
+
{| border="1" cellpadding="2" width="100%"
−
* Reacting to changes to the [[E4/Workbench_Model|workbench model]].
+
!width="15%"|Name
−
* Participating in label and icon [[E4/EAS/Decoration|Decoration]]. (Eclipse 3.x: IDecoratorManager)
+
!width="30%"|Description
−
* Reacting to changes to the [[E4/EAS/Context|Context]] (such as plug-ins that come and go). Ability to react to components coming and going at runtime. (Eclipse 3.x: IExtensionTracker)
+
!width="5%"|Priority
−
* Dynamically contributing to the [[E4/Workbench_Model|Workbench Model]] (e.g. tool items, menus, sub-parts). (Eclipse 3.x: IMenuService)
+
!width="25%"|Status
−
* [[E4/EAS/Object Contributions|Object Contributions]]. Actions that can be contributed to objects of a certain type.
+
|-
−
* [[E4/EAS/Focus Service|Focus Service]]. Enabling a task-focused interface.
+
| Workspace/Resources
 +
| Clients should be able to interact with EFS.
 +
| High
 +
| [[Image:Error.gif]] No progress. 3.x API in the org.eclipse.core.resources bundle.
 +
|-
 +
| Database Connection
 +
| N/A
 +
| High
 +
| [[Image:Progress.gif]] See IEventBroker.
 +
|-
 +
| Getting Hold of the Domain Model
 +
| Clients should be able to retrieve the model, say, in the form of an EMF model.
 +
| High
 +
| [[Image:Error.gif]] No progress.
 +
|}
  
−
=== Domain-specific ===
+
== Not Sure About These ==
−
* IWorkspace.
+
−
* Database connection.
+
−
* Getting hold of the domain model, e.g. in the form of an EMF model.
+
−
 
+
−
=== Not Sure About These ===
+
 
* String comparison/collation.
 
* String comparison/collation.
 
* "Show In" support.
 
* "Show In" support.
Line 57: Line 199:
 
* Opening a web page. (Eclipse 3.x: IWorkbenchBrowserSupport)
 
* Opening a web page. (Eclipse 3.x: IWorkbenchBrowserSupport)
  
−
=== Other Services not yet Decided on ===
+
== Other Services not yet Decided on ==
 
* From [[Architecture Council/Minutes May 15 2008#Eclipse Application Model]]:
 
* From [[Architecture Council/Minutes May 15 2008#Eclipse Application Model]]:
 
** Capabilities
 
** Capabilities
Line 70: Line 212:
 
* The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)
 
* The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)
  
−
=== Notes from e4 break out session ===
+
= Notes from e4 break out session =
 
* Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
 
* Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
 
**Does Views and Editors belong to that list?
 
**Does Views and Editors belong to that list?
Line 96: Line 238:
  
  
−
=== Comments and Discussion ===
+
 
 +
= Comments and Discussion =
  
 
''Kevin McGuire - Some of these support a component model, and some provide an application framework of common elements. It'd be worthwhile to identify this split since the former are essential for a web based Eclipse component model. For example, Selection service is needed so one can write independent views/editors and have them work together. Without it, there's no component interaction. Similarly, IMenuService and commands allow fine grain component interaction, so one plugin can say add a menu to a view it doesn't know about. UI State persistence though can be supported in a number of ways.  Help is purely an application framework item.''
 
''Kevin McGuire - Some of these support a component model, and some provide an application framework of common elements. It'd be worthwhile to identify this split since the former are essential for a web based Eclipse component model. For example, Selection service is needed so one can write independent views/editors and have them work together. Without it, there's no component interaction. Similarly, IMenuService and commands allow fine grain component interaction, so one plugin can say add a menu to a view it doesn't know about. UI State persistence though can be supported in a number of ways.  Help is purely an application framework item.''

Revision as of 13:43, 23 October 2009

a.k.a. "the twenty things"

This is a first list of "recommended APIs" - things that we expect most Eclipse plug-ins would make use of (if applicable). The goal is to reduce bloat by focusing on a smaller subset of core recommended Services and APIs. If these Services and APIs are also structured in a similar and consistent manner, it will also simplify understanding, foster Becoming More Asynchronous, and make it possible to solve the Too Many Listeners problem.

Note that "the Workbench", "PlatformUI" or "Platform" are not on this list. Think of which services you would want to use from within your contributed view or editor.

We believe that these services should be offered as separate, independent APIs, so that clients can make use of some of them without having to buy into all of them. Structuring them as individual services also makes it easier to use them from other languages / environments such as e.g. JavaScript.

There has been a discussion about if this list is too large. The conclusion is that you can build applications with subsets, but bigger applications usually need most of them. Instead of reducing the list further we want to make sure that in future there is only exactly one way to do a thing, not multiple as it is today.

Application Services

Core

Name Description Priority Status
Life Cycle A defined path of initialization and disposal for components. High Progress.gif Use JSR-250 annotations (@PostConstruct/@PreDestroy) for Java case. Not clear how to advance on JS side.
Authentication/Single Sign-on A component should be able to request authentication in a way that the end user perceives as consistent. Different backends can have different requirements, will need to support multiple mechanisms. High Error.gif No progress.
Status Handling Need a consistent way for components to report warnings / unexpected errors. High Glass.gif Clients should be able to use DI to inject a status handler for handling statuses, see org.eclipse.e4.core.services.IStatusHandler.
Logging/Tracing Components should be able to easily access a logger or provide tracing mechanisms to help with debugging. High Error.gif Clients should be able to use DI to inject a logger/tracer, see org.eclipse.e4.core.services.Logger. Note that there is also the OSGi LogService.
Extension Registry Registering and accessing extensions and extension points. High Question.gif 3.x version would be IExtensionRegistry, does this need to be updated?
Scheduling Work/Reporting Progress A component should be able to schedule work in the foreground or in the background. High Error.gif 3.x variant is IProgressService, IRunnableWithProgress, and Jobs framework.
Reading/Writing of Preferences A component should be able to schedule work in the foreground or in the background. High Glass.gif Lots of existing preferences stories in 3.x, very confusing to API consumers.
Reporting Status Users should be able to easily check the status of operations/requests. In 3.x this is done in the status line and the 'Progress' view. High Error.gif No progress.
String Localization The Eclipse Platform needs to ensure that localization can easily be done by product teams. High Error.gif No progress. See bug 226340 and bug 244468 for more information.
Adapting Objects The adapter pattern should be supported. High Question.gif 3.x version would be IAdapterManager, does this need to be updated?
Commands/Handlers Clients should be able to register handles for global commands like cut/copy/paste. High Progress.gif 3.x version would be ICommandService, IHandlerService, etc. e4 will have ECommandService, EHandlerService, and others.
Eventing System Clients should be able to monitor events easily without having a myriad of different kinds of listeners. High Progress.gif See bug 288999.

User Interface

Name Description Priority Status
Receiving Input Model objects (parts?) should be able to define an input. High Progress.gif DI can be used in this case. Currently the model would define 'input' as a variable that is modifiable by an IEclipseContext.
Providing Selection Information Different parts of the model should be able to react to current active selection of other parts. High Progress.gif DI can be used in this case. Currently the model would define 'selection' as a variable that is modifiable by an IEclipseContext. In 3.x there is ISelectionService.
Persisting State and Data The user interface must be able to remember things like its size and layouts when it has been recreated. High Error.gif In 3.x, IDialogSettings and IMemento is used.
Managing Shared Resources There should be a mechanism to pool identical resources together and share them to keep memory footprint low. High Error.gif 3.x version would be JFace's AbstractResourceManager and friends.
Participating in Undo/Redo Support Clients should be able to push operations to the undo/redo service and have it be tie in with other operations on the stack automatically. High Error.gif 3.x version would be IWorkbenchOperationSupport.
Participating in Editor/Saveable Part Life Cycle Management of dirty state, save management, prompting to save unsaved resources, etc. High Error.gif No progress.
Updating UI Elements Components should be able to modify model objects directly and the UI should update if necessary High Error.gif No progress. Tie in with 3.x databinding APIs?
Notifications Inform the user of events in the application that may require attention, regardless of whether the application is visible or not. High Error.gif No progress. See Platform UI/Notifications for ideas.

Advanced

Name Description Priority Status
Shell Provider Dialogs/Windows need to be parented off of the proper window. High Error.gif In 3.x there is JFace's IShellProvider interface. Also see bug 231150.
Reacting Workbench Model Changes. Clients should be able to listen for changes in the workbench model. High Progress.gif See IEventBroker.
Participating in Label and Icon Decoration The user interface must be able to remember things like its size and layouts when it has been recreated. High Error.gif In 3.x, there is the IDecoratorManager and an extension point for contributing decorators.
Reacting to Changes to the Context The Eclipse Platform needs to be able to react to bundles coming and going on-the-fly at runtime. High Error.gif 3.x version would be the IExtensionTracker.
Dynamically Contributing to the Workbench Model Clients should be able to add tool items, menus, parts, and other such model objects to the workbench. High Progress.gif Extension point is under development.
Object Contributions Actions that can be contributed to objects of a certain type. High Error.gif No progress.
Focus Service It should be possible to drive and enhance the presentation of the model/workbench based on the current "focus". High Error.gif No progress.

Domain-Specific

Name Description Priority Status
Workspace/Resources Clients should be able to interact with EFS. High Error.gif No progress. 3.x API in the org.eclipse.core.resources bundle.
Database Connection N/A High Progress.gif See IEventBroker.
Getting Hold of the Domain Model Clients should be able to retrieve the model, say, in the form of an EMF model. High Error.gif No progress.

Not Sure About These

  • String comparison/collation.
  • "Show In" support.
  • Hyperlink detection.
  • Opening a web page. (Eclipse 3.x: IWorkbenchBrowserSupport)

Other Services not yet Decided on

  • From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
    • Capabilities
    • Content Types, Associations
    • Markers
    • Workspace, Resources (related to Team Support)
    • Launching Framework
    • Core Variables / Launch String Substitution
    • EFS (core.filesystem)
    • OSGi Stuff (NLS, ServiceTracker, Bundle States / Activator / Classloader; Log; State Location)
  • The standard bundle layout also seems part of the Application Model ("how Eclipse is built"): MANIFEST.MF and Eclipse-specific extensions, Eclipse.inf, Features etc (related to Provisioning / Update / Plugins, Products, Features)

Notes from e4 break out session

  • Missing: Roles, logging, Usage monitoring, Life cycle, Transactions
    • Does Views and Editors belong to that list?


Data model (a rest service) 

- Adapting object
- Selection (currentSelection)
- UI Contributions
- Decorations
- Common UI Elements
- Persist State 
- Extension Registry
- roles

Command Bus (a javascript function) 

- Selection (change)
- Undo/Redo
- Handlers
- Dynamic enablement
- Notification Service
- Focus service
- logging
- usage monitoring


Comments and Discussion

Kevin McGuire - Some of these support a component model, and some provide an application framework of common elements. It'd be worthwhile to identify this split since the former are essential for a web based Eclipse component model. For example, Selection service is needed so one can write independent views/editors and have them work together. Without it, there's no component interaction. Similarly, IMenuService and commands allow fine grain component interaction, so one plugin can say add a menu to a view it doesn't know about. UI State persistence though can be supported in a number of ways. Help is purely an application framework item.

Kevin McGuire - We should have Commands as a top level item although we have an entire subject page on commands. Plus here need to tie commands in with menu service and handlers (not sure right organization)

  • From Architecture Council/Minutes May 15 2008#Eclipse Application Model:
    • Besides the List of Services we're compiling now by hand, we'll need a strong way of describing the Services for E4 -- as a medium for newcomers to understand Eclipse -- perhaps Tooling to make Service Descriptions machine readable / usable. In the beginning, Every Service should have a Wiki page describing it and the Architecture behind it (probably linked from this Summary Page.
    • Especially when Services go on the Server (Sessions, Macros Recording), need a consistent Story for exposing a Service, its state and commands, need to be Getting rid of Singletons
    • Mik to write Position Papers on new Focus Service and Notification Service
    • Application Model is related to almost all other architectural topics (Too Many Listeners, Becoming More Asynchronous, Dependency Injection, Sessions, Macro Recording)

Bjorn asks: where is the list of the global commands? Do we have a namespace of commands? Can any plug-in contribute to the set of commands? How do we know what the semantics of a given command are? -- See also E4/Commands

Retrieved from "https://wiki.eclipse.org/index.php?title=E4/Eclipse_Application_Services&oldid=176065"

Back to the top