Difference between revisions of "Issue subsystem general description"
Jump to navigation
Jump to search
(→Basics) |
|||
| Line 51: | Line 51: | ||
Typically these are computational properties and e.g. the Description is asserted in the issue type and computed from context resources. | Typically these are computational properties and e.g. the Description is asserted in the issue type and computed from context resources. | ||
| + | |||
| + | = User issues = | ||
| + | |||
| + | User issues are created by | ||
| + | |||
| + | * '''org.simantics.issues.common.IssueUtils.newUserIssue | ||
| + | * '''org.simantics.issues.common.IssueUtils.newUserIssueForModel | ||
| + | |||
| + | User issues are removed by | ||
| + | |||
| + | * '''org.simantics.db.layer0.util.RemoverUtil.remove''' | ||
| + | |||
| + | = Browsing = | ||
| + | |||
| + | For example the following requests are defined for browsing issues | ||
| + | |||
| + | * '''org.simantics.issues.common.AllIssues''' | ||
| + | * '''org.simantics.issues.common.AllActiveIssues''' | ||
| + | * '''org.simantics.issues.common.<severity>Issues''' | ||
| + | * '''org.simantics.issues.common.IssuesOfSeverity'' | ||
= Computational issues = | = Computational issues = | ||
| Line 56: | Line 76: | ||
The lifecycle of computational issues is determined by '''issue sources'''. Issue sources are divided into the following categories | The lifecycle of computational issues is determined by '''issue sources'''. Issue sources are divided into the following categories | ||
| − | * Batch issue sources, which can compute on demand a set of issues | + | * Batch issue sources, which can compute on demand a set of issues from given context |
| − | from given context | ||
* Continuous issue sources, which can track the set of issues from given context | * Continuous issue sources, which can track the set of issues from given context | ||
| Line 64: | Line 83: | ||
The issue model can be manipulated using the following codes | The issue model can be manipulated using the following codes | ||
| − | * '''org.simantics.issues.common.Issue''' and especially '''org.simantics.issues.common.StandardIssue''' for manipulating, comparing and storing issues into database. | + | * '''org.simantics.issues.common.Issue''' and especially '''org.simantics.issues.common.StandardIssue''' for manipulating, comparing and storing issues into database. StandardIssue assumes that all properties of an issue are determined by assertions in the issue type. |
| − | |||
Some utility codes can be found in | Some utility codes can be found in | ||
Revision as of 15:17, 11 March 2012
The Simantics issue subsystem is defined in various plugins including
- Issue model
- org.simantics.issues.ontology (SVN)
- Issue user interface model
- org.simantics.issues.ui.ontology (SVN)
- Headless issue code
- Issue user interface code
- org.simantics.issues.ui (SVN)
Basics
An issue describes a condition in a model. Issues are categorized by severity in the following way
- Fatal issues indicate situations which should not occur in normal operation
- Error issues indicate a severe issue which blocks calculation
- Warning issues point out a possible error
- Info issues are good to know information
- Note issues are markers for documentation purposes
Issues are somewhat related to events. The main difference between issues and events is that while events happen at a particular time, issues are conditions with a lifecycle. The different issue states are
- Active, which means that the condition is true
- Resolved, which means that the condition is no longer true
Further issues can be categorized as
- User issues, which indicates that the user has manually created the condition
- Hidden issues, which can be used as a hint for user interfaces.
The following also applies for issues
- Issues are directly linked to a model with L0.ConsistsOf
- Issues are given unique and harmless names (e.g. UUIDs)
Issues are identified by the following data
- A type resource (L0.InstanceOf)
- A list of context resources (ISSUE.Issue.HasContexts), where the first resource is a main context
All issues declare the following properties needed to e.g. display the issue in the Issue View.
- Description, which is a one-line text about the issue
- Resource, which is a textual representation of the main context resource
- Path, which us a textual representetion of the location of the main
context resource
Typically these are computational properties and e.g. the Description is asserted in the issue type and computed from context resources.
User issues
User issues are created by
- org.simantics.issues.common.IssueUtils.newUserIssue
- org.simantics.issues.common.IssueUtils.newUserIssueForModel
User issues are removed by
- org.simantics.db.layer0.util.RemoverUtil.remove
Browsing
For example the following requests are defined for browsing issues
- org.simantics.issues.common.AllIssues
- org.simantics.issues.common.AllActiveIssues
- org.simantics.issues.common.<severity>Issues
- 'org.simantics.issues.common.IssuesOfSeverity
Computational issues
The lifecycle of computational issues is determined by issue sources. Issue sources are divided into the following categories
- Batch issue sources, which can compute on demand a set of issues from given context
- Continuous issue sources, which can track the set of issues from given context
Code
The issue model can be manipulated using the following codes
- org.simantics.issues.common.Issue and especially org.simantics.issues.common.StandardIssue for manipulating, comparing and storing issues into database. StandardIssue assumes that all properties of an issue are determined by assertions in the issue type.
Some utility codes can be found in
- org.simantics.issues.common.IssueUtils
The main codes for continuous validation are
- org.simantics.issues.common.IssueUtils.listenActiveProjectIssueSources
- org.simantics.issues.common.DependencyIssueValidator2 for validating a context resource
- org.simantics.issues.common.DependencyIssueSynchronized2 for synchronizing the model
