Jump to: navigation, search

Eclipse4/RCP/Contexts

< Eclipse4‎ | RCP
Revision as of 17:30, 27 June 2012 by Bsd.mt.ca (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Stop.png
This page is a stub
This page is incomplete. Please feel free to append questions to the end.


The Eclipse 4 Application Platform uses a context to record the state used for injection. Normally code should not have to use or know about the context.

What is a Context?

A context (a IEclipseContext) is a transient key-value map with a parent, such that contexts are linked together to form a tree structure. When a key is not found in a context, the lookup is retried on the parent, repeating until either a value is found or the root of the tree has been reached.

Contexts are used as the sources for Dependency Injection.

The Use of Contexts in Eclipse 4

The power of contexts comes as Eclipse 4 associates a context with most model elements, such as that the context tree matches the UI hierarchy. So an MPart, its MPerspective, its MWindow, and its MApplication all have a separate contexts. Looking up a key that is not found in the part will cause the lookup to continue at the perspective, window, and application. At the top of the tree is a special node that looks up keys among the available OSGi services. Many application-, window-, and view-level services are installed by the Eclipse 4 at various levels in the context hierarchy. Thus the placement of values within the context hierarchy, such as in the perspective or window's context, provides a natural form of variable scoping.

Note.png
Example
For example, many client-server applications may require communicating with multiple servers, but with one server chosen as a master server at any one time. An Eclipse 4 application could record this master server in the application's context using a well-known key (e.g., "MASTER_SERVER"). All parts requesting injection for that key will have the value resolved from the application's context. Should that value change, all parts will be re-injected with the new value. A particular part could have a different master server from other parts by setting the master in that part's context. All other parts will continue to resolve MASTER_SERVER from the application. But perhaps the developers later realize that it would be very powerful to have a different master server for each window. The master could instead be set in each window's context. Or perhaps the app would prefer to have a different master server for each perspective, or even on particular part stacks. Or the app could continue to set the normal master server in the application's context, and optionally override it on a per-window basis by setting the override value in the window's context.


Context Variables

Being able to resolve a value from somewhere in the context hierarchyis very powerful. But to change the value, we need to know where in the context hierarchy the value should be set. Rather than hard code this location, we can instead declare a context variable: we declare the variable at the appropriate context, and instead modify, rather than set, the context value: the context then looks up the chain to find the variable declaration and sets the value there. This separates defining where a context value should be placed from the code that's actually setting it.

Note.png
Example (continued)
By declaring a context variable for the master server, if we later decide that we want the master-server to actually be maintained on a per-perspective basis, then we simply move the context variable definition to be on the perspective; the code obtaining and modifying the value is completely oblivious to the change.


TODO

Proposed Topics:

  • the context chain and the active context
  • getting and setting variables vs modifying a variable
  • run and tracks
  • creating a context
  • context functions
  • creating a context
  • when are contexts created?
  • how do I access the current context?

Integrate stuff from http://wiki.eclipse.org/E4/Contexts