|
|
(8 intermediate revisions by 4 users not shown) |
Line 1: |
Line 1: |
− | a.k.a. "the twenty things"
| + | #REDIRECT [[E4/Eclipse_Application_Services]] |
− | | + | |
− | 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.
| + | |
− | | + | |
− | ''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]]
| + | |
− | ** Mik to write Position Papers on new '''Focus Service''' and '''Notification Service'''
| + | |
− | ** 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)
| + | |
− | | + | |
− | * 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 [[E4/ClientServer|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)
| + | |
− | [[Category:e4]]
| + | |