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.
VIATRA Viewers is an extension framework for VIATRA currently under development. The aim of VIATRA Viewers is to provide an easy-to-use, pattern annotation-based approach to support the live visualization of query results in JFace viewers (through content provides and data bindings). In addition to "core" JFace viewers (such as Lists and Trees), VIATRA Viewers will also support the Zest Graph Visualization framework. With VIATRA Viewers, developers will be able to rapidly create rich views for their EMF domain models.
- interpretative strategy
- build an intermediate ("view") model based on annotated patterns and an instance model, and pass this through a contentprovider
- supported viewers: JFace ListViewer, JFace TreeViewer, Zest GraphViewer
- model changes are propagated with EMFIncQuery/UserDocumentation/Databinding databinding
- Viewers Sandbox (development UI)
Most important implementation classes
Creating an Internal Model to Display
- ViewerModel: parses pattern annotations and prepares Observable Lists for Items, Edges and Containments.
- Item, Edge, Containment: model representation of the various elements
- *Converters: helper classes to create Items, Edges and Containments from pattern matches
- ViewerState: a set of Observable Lists - can be reused between various viewers, and can dispose all its observable lists
- ViewerFilter: filtering support, see below
Adapting JFace Viewers
- (*)ContentProvider: content providers for various JFace Viewers
- QueryLabelProvider: label provider with support of parsing label strings
- ZestLabelProvider: special Query Label provider with formatting support
Basic filtering support
In version 0.7 there is basic support to define filters. The current implementation is not considered final, it should be used with care. Only available programmatically, the Viewers Sandbox does not support this mode of operation.
- Basic idea: call patterns with bound parameters
- For each pattern loaded into the ViewerModel
- Problem: changing the parameter bindings is equivalent of pattern changes -> full reload is required
- generative support (generate content providers)
- autorefresh on pattern change (rebuild viewer model)
- revamp devUI
- make the View fancier
- activation should happen through the pattern registry
- (temporary solution: activate annotated patterns within the same resource from a menu item in the Query Registry)
- Load model (currently contributed to model editors) should be moved to the Query Explorer