Jump to: navigation, search

Difference between revisions of "Eclipse4/API/DI"

< Eclipse4‎ | API
(The Eclipse Context)
 
(10 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
Dependency Injection ("DI") and the IEclipseContext  
 
Dependency Injection ("DI") and the IEclipseContext  
  
DI (aka 'Inversion of Concerns") is a recent development in development. It's based on teh premise that it's better for a component to describe what it needs and having those requirements met through the use of an appropriate 'context' Rather than requiring the component to rely on external frameworks through which it can satisfy its own requirements.  
+
DI (aka 'Inversion of Concerns") is a recent development in development. It's based on the premise that it's better for a component to describe what it needs and having those requirements met through the use of an appropriate 'context' Rather than requiring the component to rely on external frameworks through which it can satisfy its own requirements.  
  
 
In order for the component to expose its needs it uses a set of java annotations, some generic (@Inject, @PostConstruct...) as well as domain (e4) specific (@Focus, @CanExecute...).  
 
In order for the component to expose its needs it uses a set of java annotations, some generic (@Inject, @PostConstruct...) as well as domain (e4) specific (@Focus, @CanExecute...).  
Line 7: Line 7:
 
In order to be useful there are a number of things that must be possible:  
 
In order to be useful there are a number of things that must be possible:  
  
*Create a new instance of a class gicen the class spec and a context  
+
*Create a new instance of a class given the class spec and a context  
 
*Inject an existing instance with the values in a context  
 
*Inject an existing instance with the values in a context  
 
*Find and execute specifically annotated methods within an existing instance
 
*Find and execute specifically annotated methods within an existing instance
Line 13: Line 13:
 
== The Eclipse Context<br>  ==
 
== The Eclipse Context<br>  ==
  
In order for DI to work there must be some container from which injectable values can be retrieved. In e4 this is the IEclipseContext. In reality these contexts are defined in a tree and the values are retrieved using a lookup strategy (What is it&nbsp;?).  
+
In order for DI to work there must be some container from which injectable values can be retrieved. In e4 this is the IEclipseContext. In reality these contexts are defined in a tree and the values are retrieved using a lookup strategy (1. local value, 2. result if it's an IContextFunction, 3. delegate to parent).  
  
 
The package '''org.eclipse.e4.core.contexts''' provides the API to make, inject or uninject or to invoke specifically annotated methods on an Object.  
 
The package '''org.eclipse.e4.core.contexts''' provides the API to make, inject or uninject or to invoke specifically annotated methods on an Object.  
Line 31: Line 31:
 
|-
 
|-
 
| IContextFunction  
 
| IContextFunction  
| An interface containing a single method 'compute'. ContextFuncton implements this interface but since we expect that clients will be implementing instances of this '''''<u>we should likely remove (deprecate?) this interface in favor of supplying the base class</u>''.
+
| An interface containing a single method 'compute'. ContextFuncton implements this interface but since we expect that clients will be implementing instances of this '''''<u>we should likely remove (deprecate?) this interface in favor of supplying the base class</u>''.'''
 
|-
 
|-
 
| IEclipseContext  
 
| IEclipseContext  
 
| The interface through which context information is accessed. There are far many methods here...are they all really needed&nbsp;?
 
| The interface through which context information is accessed. There are far many methods here...are they all really needed&nbsp;?
 +
modify(*)/declareModifiable(*) - it looks like it can be used to set a value up a chain of contexts to the parent chain.
 +
The other methods all have uses in the SDK
 
|-
 
|-
 
| RunAndTrack  
 
| RunAndTrack  
| An abstract class containing a single abstract mehtod 'changed' and a utility method 'runExternalCode' (should this be final?)
 
|-
 
|
 
 
|  
 
|  
 +
An abstract class containing a single abstract mehtod 'changed' and a utility method 'runExternalCode' (should this be final?)
 +
 +
|-
 +
| <br>
 +
| <br>
 
|}
 
|}
 +
 +
<br>
 +
 +
The package&nbsp;'''org.eclipse.e4.core.di.annotations''' contains a variety of generally useful anotations:
 +
 +
*CanExecute - commands/handlers are headless<br>
 +
*Creatable<br> '''''<u>What about @Singleton? </u>'' [[User:Lars Vogel|Lars.Vogel@gmail.com]]
 +
*Execute - commands/handlers are headless<br>
 +
*GroupUpdates<br>
 +
*Optional<br>
 +
 +
We should make '''org.eclipse.e4.core.di.suppliers''' provisional for now.
 +
:This section is used to provide extra annotations used for injection or invocation, like ''org.eclipse.e4.core.di.extensions.Preference'' [[User:Pwebster.ca.ibm.com|Pwebster.ca.ibm.com]]
 +
 +
<br>
 +
 +
The package '''org.eclipse.e4.ul.di''' contains a variety of ui specific annotations:<br>
 +
 +
*AboutToHide<br>
 +
*AboutToShow
 +
*Focus
 +
*Persist
 +
*PersistState (How is this different from 'Persist'&nbsp;?)  '''''<u>It  saves the UI state of a Part, Persists works together with Dirty to save the data model </u>'' [[User:Lars Vogel|Lars.Vogel@gmail.com]]
 +
*UIEventTopic
 +
*UISynchronize (How is this used?) '''''<u>It is used as a replacement for Display.asyncExec and Display.asyncExec </u>'' [[User:Lars Vogel|Lars.Vogel@gmail.com]]
 +
 +
 +
We may want to add some other life-cycle annotations here as well but they needn't be declared API for Kepler
 +
 +
 +
 +
 +
<br>
 +
 +
== Discussion  ==
 +
 +
Maybe this is handled somewhere else but what about @UIEventTopic and @EventTopic and @Preference

Latest revision as of 15:18, 6 March 2013

Dependency Injection ("DI") and the IEclipseContext

DI (aka 'Inversion of Concerns") is a recent development in development. It's based on the premise that it's better for a component to describe what it needs and having those requirements met through the use of an appropriate 'context' Rather than requiring the component to rely on external frameworks through which it can satisfy its own requirements.

In order for the component to expose its needs it uses a set of java annotations, some generic (@Inject, @PostConstruct...) as well as domain (e4) specific (@Focus, @CanExecute...).

In order to be useful there are a number of things that must be possible:

  • Create a new instance of a class given the class spec and a context
  • Inject an existing instance with the values in a context
  • Find and execute specifically annotated methods within an existing instance

The Eclipse Context

In order for DI to work there must be some container from which injectable values can be retrieved. In e4 this is the IEclipseContext. In reality these contexts are defined in a tree and the values are retrieved using a lookup strategy (1. local value, 2. result if it's an IContextFunction, 3. delegate to parent).

The package org.eclipse.e4.core.contexts provides the API to make, inject or uninject or to invoke specifically annotated methods on an Object.


Active This defines an injection annotation that we don'd appear to use and should be deleted
ContextFunction Defines an abstract class with a single abstract method 'compute' that is called whenever the value is retrieved from an IEclipseContext.
ContextInjectionFactory  Defines the 'inject', 'make' and 'uninject' methods used to manipulate objects through injection. It also contains a 'setDefault' method that should not be API.
IContextFunction An interface containing a single method 'compute'. ContextFuncton implements this interface but since we expect that clients will be implementing instances of this we should likely remove (deprecate?) this interface in favor of supplying the base class.
IEclipseContext The interface through which context information is accessed. There are far many methods here...are they all really needed ?

modify(*)/declareModifiable(*) - it looks like it can be used to set a value up a chain of contexts to the parent chain. The other methods all have uses in the SDK

RunAndTrack

An abstract class containing a single abstract mehtod 'changed' and a utility method 'runExternalCode' (should this be final?)




The package org.eclipse.e4.core.di.annotations contains a variety of generally useful anotations:

  • CanExecute - commands/handlers are headless
  • Creatable
    What about @Singleton? Lars.Vogel@gmail.com
  • Execute - commands/handlers are headless
  • GroupUpdates
  • Optional

We should make org.eclipse.e4.core.di.suppliers provisional for now.

This section is used to provide extra annotations used for injection or invocation, like org.eclipse.e4.core.di.extensions.Preference Pwebster.ca.ibm.com


The package org.eclipse.e4.ul.di contains a variety of ui specific annotations:

  • AboutToHide
  • AboutToShow
  • Focus
  • Persist
  • PersistState (How is this different from 'Persist' ?) It saves the UI state of a Part, Persists works together with Dirty to save the data model Lars.Vogel@gmail.com
  • UIEventTopic
  • UISynchronize (How is this used?) It is used as a replacement for Display.asyncExec and Display.asyncExec Lars.Vogel@gmail.com


We may want to add some other life-cycle annotations here as well but they needn't be declared API for Kepler




Discussion

Maybe this is handled somewhere else but what about @UIEventTopic and @EventTopic and @Preference