Skip to main content
Jump to: navigation, search

Difference between revisions of "VIATRA/Query/DeveloperDocumentation/FeatureSetAndTesting/Validationframework"

(Validation framework)
Line 4: Line 4:
 
----
 
----
  
* generator
+
* Generator (Host Eclipse)
 
** EMF-IncQuery Validation -> Initialize EMF-IncQuery Validators on Editor
 
** EMF-IncQuery Validation -> Initialize EMF-IncQuery Validators on Editor
  
Line 12: Line 12:
 
After defining a pattern with constraint, a .validation project is generated.
 
After defining a pattern with constraint, a .validation project is generated.
  
* runtime
+
* Runtime (Runtime Eclipse)
** start validation (launching .incquery and .incquery.validation projects as an Eclipse application)
+
** start validation (launching .incquery and .incquery.validation projects as an Eclipse application - on host Eclipse)
 
*** marker management
 
*** marker management
 
**** live synchronization with the EMF instance model (if the model changes, the message appears in the „Problem view”)
 
**** live synchronization with the EMF instance model (if the model changes, the message appears in the „Problem view”)
 
**** navigate to source (element of the instance model) (Right clikk -> „Go to”)
 
**** navigate to source (element of the instance model) (Right clikk -> „Go to”)
 
**** displayed information: description, resource, path, location, type
 
**** displayed information: description, resource, path, location, type
 +
 
* @Constraint annotation has influence on behaviour
 
* @Constraint annotation has influence on behaviour
 +
** key (list of parameter names as strings): The keys of a constraint represent the parameters that together identify a given violation. Multiple matches of the same constraint pattern with the same parameter values for keys will be considered as a single violation. Non-key parameters can be accessed as tuples by the API.
 +
** message (format string): The message to display when the constraint violation is found. The message may refer the key variables between $ symbols, or their EMF features, such as in $keyParam1.name$.
 +
** severity (string): "info", "warning" or "error"
 +
** targetEditorId (string): An Eclipse editor ID where the validation framework should register itself to the context menu. Use "*" as a wildcard if the constraint should be used always when validation is started.
 +
** symmetric (possibly multiple list of parameter names as strings): Parameters listed as symmetric are considered to correspond to the same violation for matches where the values are in a different permutation. Symmetric parameters can be either keys or non-keys, mixing is not allowed.
  
  
 
[[File:problems.png|900px|center]]
 
[[File:problems.png|900px|center]]
 +
 +
Constraint violation markers will be placed in the Problems view. Note that the markers are data-bound to corresponding model elements and the labels will be automatically refreshed (when the model changes).
 +
 +
For more information visit: [[https://wiki.eclipse.org/EMFIncQuery/UserDocumentation/Validation Here]]

Revision as of 04:58, 30 March 2015

Validation framework

EMF-IncQuery provides facilities to create validation rules based on the pattern language of the framework. These rules can be evaluated on various EMF instance models and upon violations of constraints, markers are automatically created in the Eclipse Problems View.


  • Generator (Host Eclipse)
    • EMF-IncQuery Validation -> Initialize EMF-IncQuery Validators on Editor
Generator.png


After defining a pattern with constraint, a .validation project is generated.

  • Runtime (Runtime Eclipse)
    • start validation (launching .incquery and .incquery.validation projects as an Eclipse application - on host Eclipse)
      • marker management
        • live synchronization with the EMF instance model (if the model changes, the message appears in the „Problem view”)
        • navigate to source (element of the instance model) (Right clikk -> „Go to”)
        • displayed information: description, resource, path, location, type
  • @Constraint annotation has influence on behaviour
    • key (list of parameter names as strings): The keys of a constraint represent the parameters that together identify a given violation. Multiple matches of the same constraint pattern with the same parameter values for keys will be considered as a single violation. Non-key parameters can be accessed as tuples by the API.
    • message (format string): The message to display when the constraint violation is found. The message may refer the key variables between $ symbols, or their EMF features, such as in $keyParam1.name$.
    • severity (string): "info", "warning" or "error"
    • targetEditorId (string): An Eclipse editor ID where the validation framework should register itself to the context menu. Use "*" as a wildcard if the constraint should be used always when validation is started.
    • symmetric (possibly multiple list of parameter names as strings): Parameters listed as symmetric are considered to correspond to the same violation for matches where the values are in a different permutation. Symmetric parameters can be either keys or non-keys, mixing is not allowed.


Problems.png

Constraint violation markers will be placed in the Problems view. Note that the markers are data-bound to corresponding model elements and the labels will be automatically refreshed (when the model changes).

For more information visit: [Here]

Back to the top