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 "Eclipse4/API"

(Eclipse 4 API)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
= Eclipse 4 API =
+
{{Eclipse4}}
 +
The Eclipse 4 platform is currently defining its API for the Eclipse 4.3 release.
 +
 
 +
== Areas we need to consider for API in Mars ==
 +
 
 +
[[Eclipse4/API/AppContext|Application Context]] - Defines what is guaranteed to be available in a particular context; Services, MApplication, Selection...
 +
 
 +
[[Eclipse4/API/CSS|CSS]] - The CSS attributes as well as the API needed to support adding CSS support to arbitrary elements (such as the framing support for trim elements...)
 +
 
 +
 
 +
 
 +
== API defined in 4.3 ==
 +
 
 +
[[Eclipse4/API/UIModel|Application model]] - The EMF model that defines the User Interface along with any defined constants used as tags or as keys for either persistent or transient data. Also the API used to render the UI Model.
 +
 
 +
[[Eclipse4/API/DI|Dependency Injection and Annotations]] - The dependency injection API and Eclipse 4 relevant annotations
 +
 
 +
== About this page ==
  
 
This will eventually be the definitive source for information / documentation on the various different Eclipse 4 APIs. The API will include those parts of the existing e4 API that we decide to graduate out of the incubator as well as the changes in the IDE's API which are needed in order to allow the use of e4-native implementations into Eclipse 4.  
 
This will eventually be the definitive source for information / documentation on the various different Eclipse 4 APIs. The API will include those parts of the existing e4 API that we decide to graduate out of the incubator as well as the changes in the IDE's API which are needed in order to allow the use of e4-native implementations into Eclipse 4.  
Line 5: Line 22:
 
Since this is our first attempt to formalize the API we should likely declare only those parts that we are ''sure ''are in fact needed and where we don't anticipate needing to make future revisions. Once we formally declare API it then becomes our problem to <u>'''guarantee'''</u> that future releases support it so if we're not sure then it's likely best to mark it provisional for now.
 
Since this is our first attempt to formalize the API we should likely declare only those parts that we are ''sure ''are in fact needed and where we don't anticipate needing to make future revisions. Once we formally declare API it then becomes our problem to <u>'''guarantee'''</u> that future releases support it so if we're not sure then it's likely best to mark it provisional for now.
  
The e4 API can be broken into a number of distinct areas:
+
== Tooling changes ==
 
+
*[[Eclipse4/API/UIModel|UI Model]] - This is the EMF model we use to define the User Interface along with any defined constants used as tags or as keys for either persistant or transient data. It also includes the API used to render the UI Model.
+
*[[Eclipse4/API/DI|DI / IEclipseContext]] - This includes the DI api itself as well as any Eclipse 4 relevant annotations
+
*[[Eclipse4/API/AppContext|Application Context]]&nbsp; - This includes ''anything'' that we guarantee will be available in a particular context; Services, MApplication, Selection...
+
*[[Eclipse4/API/CSS|CSS]] - This includes the CSS attributes as well as the API needed to support adding CSS support to arbitrary elements (such as the framing support for trim elements...)
+
  
 
The changes necessary to support e4-natives directly in the IDE is as yet TBD but will (at least initially) involve modifying the definition and management of some subset of the current extension points, likely candidates are:
 
The changes necessary to support e4-natives directly in the IDE is as yet TBD but will (at least initially) involve modifying the definition and management of some subset of the current extension points, likely candidates are:

Latest revision as of 15:12, 20 June 2014

The Eclipse 4 platform is currently defining its API for the Eclipse 4.3 release.

Areas we need to consider for API in Mars

Application Context - Defines what is guaranteed to be available in a particular context; Services, MApplication, Selection...

CSS - The CSS attributes as well as the API needed to support adding CSS support to arbitrary elements (such as the framing support for trim elements...)


API defined in 4.3

Application model - The EMF model that defines the User Interface along with any defined constants used as tags or as keys for either persistent or transient data. Also the API used to render the UI Model.

Dependency Injection and Annotations - The dependency injection API and Eclipse 4 relevant annotations

About this page

This will eventually be the definitive source for information / documentation on the various different Eclipse 4 APIs. The API will include those parts of the existing e4 API that we decide to graduate out of the incubator as well as the changes in the IDE's API which are needed in order to allow the use of e4-native implementations into Eclipse 4.

Since this is our first attempt to formalize the API we should likely declare only those parts that we are sure are in fact needed and where we don't anticipate needing to make future revisions. Once we formally declare API it then becomes our problem to guarantee that future releases support it so if we're not sure then it's likely best to mark it provisional for now.

Tooling changes

The changes necessary to support e4-natives directly in the IDE is as yet TBD but will (at least initially) involve modifying the definition and management of some subset of the current extension points, likely candidates are:

  • org.eclipse.ui.views - Need to relax the restriction that all views are subclasses of ViewPart and make sure that we create these views using DI rather that 'wrapping' them in the LegacyPart...
  • org.eclipse.ui.perspectives - See what changes we can make to allow an IPerspectiveFactory to skip teh current API and create the UI model for the perspective using e4 api (perhaps using snippets?)
  • org.eclipse.ui.handlers - relax the restriction that handlers implement IHandler and make sure that the IDE code recognizes e4 elements and creates them through DI.

As we proceed we can see what we can do to augment the PDE mechanism (i.e. now it knows enough to create a class that's a subclass of 'ViewPart' but the e4 alternative would be to generate a POJO with an @PostConstruct 'createPart' and @Focus methods)

Back to the top