- 1 Overview
- 2 UI Model
- 3 Logical Model
An e4 application is completely backed up by a domain model often called Workbench or Application Model but in contrast to e.g. the browser DOM which only holds visual elements the e4 application model also holds other informations relevant to an e4 application (e.g. commands, handlers, ...). This makes the e4 application model the center of each e4 application.
From a technical point of view the e4 application model is defined using EMFs Ecore meta model. For an average user the usage of EMF in the background is completely transparent and you don't need to know about EMF to write an develop e4 applications (you won't even notice that you are using EMF because the API presented to you is not holding EMF-Types). For people who'd like to extend the workbench model a certain knowlegde about EMF is certainly needed.
As outlined before the application model holds the main UI structure of an e4 application. When we talk about the main UI structure this means everything part of the Application Window (Menus, PartStacks, ...) and e.g. Part menus but not the UI shown inside an application Part (e.g. the Tree in the PackageExplorer)
One of the most important things when talking about the application model we need to know that ALL modification made in the model are immediately reflected in the UI. It is in contrast so that you are only programming against the application model and not against its visual representation. This now is indeed similar to how you are implementing Browser-Applications where also modify the DOM and the browser updates the visual representation.
The ui-domain objects are organized in 3 different packages:
- menu: Holding menu and toolbar domain objects
- basic: Basic UI domain objects e.g. to create windows, stacks, ...
- advanced: Advanced UI domain objects e.g. to create perspectives
Basic UI Domain Objects
These domain objects are needed to write a simple to medium size e4 application providing you with the most common UI concepts like Window, Sash and Stack.
There are 2 domain types available to define a window in your application.
Represents a standard window used by application who are not in need of advanced stuff.
|mainMenu||Menu||The main menu shown in the menubar of the Shell|
|x||int||The x position on the screen|
|width||int||The width of the window|
|height||int||The height of the window|
|bindingContexts||List<String>||Keybinding contexts active in this window|
|context||IEclipseContext||The IEclipseContext used by the DI-Framework for injection|
|variables||List<String>||Variables defined in this context (see IEclipseContext description)|
|children||List<MWindowElement>||Child elements layouted in the windows content pane|
|selectedElement||MWindowElement||The currently active childcontrol|
|widget||Object||the real UI-Control (e.g. SWT-Widget) rendering the element|
|renderer||Object||The renderer resposible to create the UI-Control and sync it with the elements attribute|
|parent||MElementContainer<MUIElement>||The parent container|
|elementId||String||id to identify the element e.g. when contributing|
|tags||List<String>||Arbitary strings used to tag elements so that one can query for them|
|handlers||List<MHandler>||list of handlers|
|label||String||The label displayed on the window|
|iconURI||String||The icon displayed on the window|
Represents a window with TrimBars e.g. to show a ToolBar at the top, a StatusBar at the bottom and minimized Stacks at the right and left
|trimBars||List<MTrimBar>||TrimBars who hold e.g. the ToolBar, Minimized Stacks, ...|