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.
Difference between revisions of "Eclipse4/API/UIModel"
(New page: = UI Model = The UI Model is used to describe the various components of an application's User Interface. This model is an abstract definition that is rendered into reality on a particular...) |
|||
| Line 1: | Line 1: | ||
| − | = UI Model = | + | = UI Model = |
| − | The UI Model is used to describe the various components of an application's User Interface. This model is an abstract definition that is rendered into reality on a particular platform through the use of a presentation engine driving a set of renderers (usually but not limited to one renderer part UI Model type. | + | The UI Model is used to describe the various components of an application's User Interface. This model is an abstract definition that is rendered into reality on a particular platform through the use of a presentation engine driving a set of renderers (usually but not limited to one renderer part UI Model type. |
| − | The model itself is based on EMF. One of the things that EMF does a really good job at is allowing multiple inheritance so the basic design of the model starts with low-level components that can then be aggregated into concrete classes. | + | The model itself is based on EMF. One of the things that EMF does a really good job at is allowing multiple inheritance so the basic design of the model starts with low-level components that can then be aggregated into concrete classes. |
| − | The model itself is composed from a number of different type of elements which are used to define the 'concrete' UI elements (i.e. the ones that actually get rendered): | + | The model itself is composed from a number of different type of elements which are used to define the 'concrete' UI elements (i.e. the ones that actually get rendered): |
| − | *Mix-ins - Used to contain the attributes for different concepts such as label information or containment types. These will be useful when we eventually start to derive domain-specific models based on the current one. | + | *Mix-ins - Used to contain the attributes for different concepts such as label information or containment types. These will be useful when we eventually start to derive domain-specific models based on the current one. |
| − | **ContainmentDefinitions - In order to facilitate the use of Java generics each container may only contain elements of a single 'type' (interface really). These elements represent the type that is legal in a given container. In order to make an element legal for a given container add that container's type as one of the mix-ins for the class being contained. | + | **ContainmentDefinitions - In order to facilitate the use of Java generics each container may only contain elements of a single 'type' (interface really). These elements represent the type that is legal in a given container. In order to make an element legal for a given container add that container's type as one of the mix-ins for the class being contained. |
*Concrete Classes - These define the true UI model as used to present an applicaton. | *Concrete Classes - These define the true UI model as used to present an applicaton. | ||
Revision as of 16:05, 7 February 2013
UI Model
The UI Model is used to describe the various components of an application's User Interface. This model is an abstract definition that is rendered into reality on a particular platform through the use of a presentation engine driving a set of renderers (usually but not limited to one renderer part UI Model type.
The model itself is based on EMF. One of the things that EMF does a really good job at is allowing multiple inheritance so the basic design of the model starts with low-level components that can then be aggregated into concrete classes.
The model itself is composed from a number of different type of elements which are used to define the 'concrete' UI elements (i.e. the ones that actually get rendered):
- Mix-ins - Used to contain the attributes for different concepts such as label information or containment types. These will be useful when we eventually start to derive domain-specific models based on the current one.
- ContainmentDefinitions - In order to facilitate the use of Java generics each container may only contain elements of a single 'type' (interface really). These elements represent the type that is legal in a given container. In order to make an element legal for a given container add that container's type as one of the mix-ins for the class being contained.
- Concrete Classes - These define the true UI model as used to present an applicaton.