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 "E4/DeclarativeUI/HintedUI"
m |
|||
| Line 15: | Line 15: | ||
'''Description''': | '''Description''': | ||
| − | This is somewhat orthogonal to other approaches to [[ | + | This is somewhat orthogonal to other approaches to [[E4/DeclarativeUI|Declarative UI]]. I have a working prototype but it would need a rewrite for E4. |
The current implementation assumes the underlying model is EMF, but this could be relaxed to a model that supports databinding. The assumption is that all logic is in the model. The UI is generic and provides no functionality. UI hinting can be seen as a set of transformation steps: A simple model of the UI is created based on the structural features (similar to the properties view). Then each UI hint contribution can transform the UI model. There is obviously an issue of the order in which the hints are applied. | The current implementation assumes the underlying model is EMF, but this could be relaxed to a model that supports databinding. The assumption is that all logic is in the model. The UI is generic and provides no functionality. UI hinting can be seen as a set of transformation steps: A simple model of the UI is created based on the structural features (similar to the properties view). Then each UI hint contribution can transform the UI model. There is obviously an issue of the order in which the hints are applied. | ||
Latest revision as of 23:29, 4 November 2008
HintedUI
Purpose: The basic idea is to use "hints" to drive the UI. This is similar to using layout managers. Layout managers take some freedom to arrange items in the UI.
Contact: Michael Scharf
Committers: Michael Scharf. Well, this is currently an internal project at Wind River.
Current License: Internal project at Wind River -- I am pretty sure it can be made available under EPL.
Description:
This is somewhat orthogonal to other approaches to Declarative UI. I have a working prototype but it would need a rewrite for E4.
The current implementation assumes the underlying model is EMF, but this could be relaxed to a model that supports databinding. The assumption is that all logic is in the model. The UI is generic and provides no functionality. UI hinting can be seen as a set of transformation steps: A simple model of the UI is created based on the structural features (similar to the properties view). Then each UI hint contribution can transform the UI model. There is obviously an issue of the order in which the hints are applied.
In eclipse there already some incarnations of such an UI: [property discriptors], [Field Editors], [Tabbed Properties View][Using Preference Pages as Property Pages].
The HintedUI approach goes a step further: it would provide some hints on the model elements that are then transformed into a wizard page, a property page, a editor page, a preference page etc.
There are three major elements:
- the model
- the hints
- the layout engine
The model provides the logic of the application. All validation and notifications have to be done by the model.
The hints can come form different sources: form the model itself, via annotation or some other source (like an external hint file).
The layout engine takes the hints and produces a layout. It is possible to contribute new layout engines or bits in the layout engine. It is also be possible to provide specific UI elements for particular model elements.
Note that the UI does not have to be graphical. It should also be possible to generate command line UIs or terminal (cursers) style UI.
This approach facilitates a strict separation of model and UI.