Jump to: navigation, search

Difference between revisions of "E4/Eclipse Application Services"

< E4
Line 1: Line 1:
 +
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 [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], and make it possible to solve the [[Architecture Council/Minutes May 15 2008#Too Many Listeners|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.
 +
 +
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 ===
 
=== Fundamentals ===
* Life cycle - initialization and disposal.
+
* [[E4/EAS/Life Cycle|Life Cycle]] - initialization and disposal.
* [[Image:Glass.gif]] Authorization (single sign on)
+
* [[Image:Glass.gif]] [[E4/EAS/Authorization|Authorization]] (single sign on)
* [[Image:Progress.gif]] Status handling (errors and warnings).
+
* [[Image:Progress.gif]] [[E4/EAS/Status Handling}Status Handling]] (errors and warnings).
* Logging over and above status handling.
+
* [[E4/EAS/Logging|Logging]] over and above status handling.
* Scheduling background work.
+
* [[E4/EAS/Scheduling Background Work|Scheduling Background Work]].
* Accessing preferences (mostly read access, but sometimes write access).
+
* Accessing [[E4/EAS/Preferences|Preferences]] (mostly read access, but sometimes write access).
* [[Image:Progress.gif]] Reporting status (think status line).
+
* [[Image:Progress.gif]] [[E4/EAS/Reporting Status|Reporting Status]] (think status line).
* String localization.
+
* [[E4/EAS/String Localization|String Localization]].
* Adapting objects.
+
* [[E4/EAS/Adapting Objects|Adapting Objects]].
  
 
=== Specific to UI Parts ===
 
=== Specific to UI Parts ===
* [[Image:Glass.gif]] Receiving input.
+
* [[Image:Glass.gif]] [[E4/EAS/Receiving Input|Receiving Input]].
* [[Image:Glass.gif]] Producing selection.
+
* [[Image:Glass.gif]] [[E4/EAS/Producing Selection|Producing Selection]].
* Persisting data (receiving persisted state, and producing persistable state).
+
* [[E4/EAS/Persisting Data|Persisting Data]] (receiving persisted state, and producing persistable state).
* Managing shared resources (e.g. JFace LocalResourceManager).
+
* [[E4/EAS/Managing Shared Resources|Managing Shared Resources]] (e.g. JFace LocalResourceManager).
* Connecting to the help system.
+
* Connecting to the [[E4/EAS/Help|Help]] system.
* Participating in Undo/Redo.
+
* Participating in [[E4/EAS/Undo Redo|Undo/Redo]].
* [[Image:Progress.gif]] Participating in editor lifecycle (units of saveability, dirtiness, saving, prompting to save).
+
* [[Image:Progress.gif]] Participating in [[E4/EAS/Editor Lifecycle|Editor Lifecycle]] (units of saveability, dirtiness, saving, prompting to save).
* Updating enablement, labels, icons of menu and tool items.
+
* [[E4/EAS/Updating UI Elements|Updating UI Elements]] such as e.g. enablement, labels, icons of menu and tool items.
* Registering command handlers.
+
* Registering handlers for [[E4/EAS/Commands|Commands]].
  
 
=== Specific to Command Handlers ===
 
=== Specific to Command Handlers ===
* [[Image:Glass.gif]] Reporting progress and responding to cancellation requests.
+
* [[Image:Glass.gif]] [[E4/EAS/Reporting Progress|Reporting Progress]] including responding to cancellation requests.
  
 
=== Advanced ===
 
=== Advanced ===
* Shell Provider (for properly parenting dialogs).
+
* [[E4/EAS/Shell Provider|Shell Provider]] (for properly parenting dialogs).
 
* Reacting to changes to the [[E4/Workbench_Model|workbench model]].
 
* Reacting to changes to the [[E4/Workbench_Model|workbench model]].
* Participating in label and icon decoration.
+
* Participating in label and icon [[E4/EAS/Decoration|Decoration]].
* Reacting to changes to the context (such as plug-ins that come and go).
+
* Reacting to changes to the [[E4/EAS/Context|Context]] (such as plug-ins that come and go).
* Dynamically contributing to the [[E4/Workbench_Model|workbench model]] (e.g. tool items, menus, sub-parts).
+
* Dynamically contributing to the [[E4/Workbench_Model|Workbench Model]] (e.g. tool items, menus, sub-parts).
 
* Object contributions (actions that can be contributed to objects of a certain type).
 
* Object contributions (actions that can be contributed to objects of a certain type).
  
Line 41: Line 49:
 
* "Show In" support.
 
* "Show In" support.
 
* Hyperlink detection.
 
* Hyperlink detection.
 +
 +
=== 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 [[E4/Commands | 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 [[Architecture Council/Minutes May 15 2008#Getting rid of Singletons|Getting rid of Singletons]]
 +
** <s>Mik to write Position Papers on new '''Focus Service''' and '''Notification Service'''</s>
 +
** Application Model is related to almost all other architectural topics ([[Architecture Council/Minutes May 15 2008#Too Many Listeners|Too Many Listeners]], [[Architecture Council/Minutes May 15 2008#Becoming More Asynchronous|Becoming More Asynchronous]], [[Architecture Council/Minutes May 15 2008#Dependency Injection|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]]

Revision as of 12:18, 16 January 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.

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

Specific to UI Parts

Specific to Command Handlers

Advanced

  • Shell Provider (for properly parenting dialogs).
  • Reacting to changes to the workbench model.
  • Participating in label and icon Decoration.
  • Reacting to changes to the Context (such as plug-ins that come and go).
  • Dynamically contributing to the Workbench Model (e.g. tool items, menus, sub-parts).
  • Object contributions (actions that can be contributed to objects of a certain type).

Domain-specific

  • 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.
  • "Show In" support.
  • Hyperlink detection.

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