Difference between revisions of "E4/Eclipse Application Services"

Revision as of 13: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

• Life Cycle - initialization and disposal.
• Authorization (single sign on)
• [[E4/EAS/Status Handling}Status Handling]] (errors and warnings).
• Logging over and above status handling.
• Scheduling Background Work.
• Accessing Preferences (mostly read access, but sometimes write access).
• Reporting Status (think status line).
• String Localization.
• Adapting Objects.

Specific to UI Parts

• Receiving Input.
• Producing Selection.
• Persisting Data (receiving persisted state, and producing persistable state).
• Managing Shared Resources (e.g. JFace LocalResourceManager).
• Connecting to the Help system.
• Participating in Undo/Redo.
• Participating in Editor Lifecycle (units of saveability, dirtiness, saving, prompting to save).
• Updating UI Elements such as e.g. enablement, labels, icons of menu and tool items.
• Registering handlers for Commands.

Specific to Command Handlers

• Reporting Progress including responding to cancellation requests.

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