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/Eclipse Application Model"

< E4
Line 1: Line 1:
 
a.k.a. "the twenty things"
 
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).
+
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.
 
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.

Revision as of 16:27, 19 May 2008

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.

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)
  • One goal of this session could be to organize services into some grouping with similar Properties.
    • For instance, IExtensionRegistry, IAdapterManager, IProgressService and IPreferencesService seem to be similar in that they are all very low-level, non-UI services.
    • Kevin also mentioned the "component model" vs. "application framework" kind of separation.
    • Another separation could be Services that maintain some kind of internal state / require session information vs. others that do not.
    • Yet another separation could go along the lines of Client / Server split: What could go on the client and what could go on the Server.

Selection

ISelectionService - Listening to the current selection

Adapting objects

IAdapterManager - adapt an object (typically, the current selection) to a type that is relevant to the current plug-in

Scheduling background work

IProgressService - Schedule work in a way that is visible to the user Job, IJobManager - schedule and manage background jobs

Help

IWorkbenchHelpSystem

Undo/Redo

IWorkbenchOperationSupport

Preferences

IPreferencesService - retrieve and modify preferences

Handlers

IHandlerService - register a handler for a global command like Copy/Paste

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

UI Contributions

IMenuService - programmatic contribution to menus and toolbars

Open web pages

IWorkbenchBrowserSupport

Decorations

IDecoratorManager

Common UI Elements

Wizard framework, Dialogs --- Added - KevinM

Dynamic enablement

IExtensionTracker - ability to react to components coming and going at runtime

UI state persistence

IDialogSettings, IMemento - Persistence of UI state: layouts, dialog sizes, viewer selection and expansion state

Extension registry

IExtensionRegistry - registering and accessing extensions and extension points

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)

Back to the top