Difference between revisions of "Issue subsystem general description"

From Developer Documents
Jump to navigation Jump to search
Line 14: Line 14:
  
 
An issue describes a condition in a model. Issues are categorized by
 
An issue describes a condition in a model. Issues are categorized by
−
severity in the following way
+
'''severity''' in the following way
  
−
* '''Fatal''' issues describe severe errors which for example prevent simulation
+
* '''Fatal''' issues indicate situations which should not occur in normal operation
−
* '''Error''' issues describe clear errors, which require user attention
+
* '''Error''' issues indicate a severe issue which blocks calculation
−
* '''Warning''' issues are indications that something may be wrong
+
* '''Warning''' issues point out a possible error
−
* '''Note''' issues are reminders about important things
+
* '''Info''' issues are good to know information
−
* '''Info''' issues are pieces of information linked to objects
+
* '''Note''' issues are markers for documentation purposes
  
−
Issues are somewhat related to events. The main difference between
+
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
−
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
+
* '''Active''', which means that the condition is true
−
* Resolved, which means that the condition is no longer true
+
* '''Resolved''', which means that the condition is no longer true
  
−
Issues are identified by the following data
+
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.
  
−
* A type resource
+
The following also applies for issues
−
* A main context resource
 
−
* A list of secondary context resources
 
  
−
§ All issues are required to be part of a model (by ConsistsOf).
+
* Issues are directly linked to a model with L0.ConsistsOf and named with UUIDs.
−
§ All issues are managed by an issue source
 
  
−
Issue sources are divided into the following categories
+
Issues are identified by the following data
  
−
* Batch issue sources, which can compute on demand a set of issues
+
* A type resource (L0.InstanceOf)
−
from given context
+
* A list of context resources (ISSUE.Issue.HasContexts), where the first resource is a '''main context'''
−
* Continuous issue sources, which can track the set of issues from given context
 
  
 
All issues declare the following properties needed to e.g. display the
 
All issues declare the following properties needed to e.g. display the
Line 53: Line 48:
 
* Path, which us a textual representetion of the location of the main
 
* Path, which us a textual representetion of the location of the main
 
context resource
 
context resource
 +
 +
Typically these are computational properties and e.g. the Description is asserted in the issue type and computed from context resources.
 +
 +
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

Revision as of 14:59, 11 March 2012

The Simantics issue subsystem is defined in various plugins including

  • Issue model
    1. org.simantics.issues.ontology (SVN)
  • Issue user interface model
    1. org.simantics.issues.ui.ontology (SVN)
  • Headless issue code
    1. org.simantics.issues (SVN)
    2. org.simantics.issues.common (SVN)
  • Issue user interface code
    1. 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 and named with 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.

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
Retrieved from "https://dev.simantics.org/index.php?title=Issue_subsystem_general_description&oldid=2675"