Documentation/4.1/Developers/Logics - Revision history

UpdateBot: Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887

2013-06-14T07:21:09Z

Prepend documentation/versioncheck template. See http://na-mic.org/Mantis/view.php?id=2887

Matt.mccormick at 14:54, 20 June 2012

2012-06-20T14:54:43Z

JChris.FillionR at 07:42, 13 June 2012

2012-06-13T07:42:35Z

JChris.FillionR at 07:40, 13 June 2012

2012-06-13T07:40:38Z

JChris.FillionR at 07:40, 13 June 2012

2012-06-13T07:40:10Z

JChris.FillionR at 07:39, 13 June 2012

2012-06-13T07:39:07Z

JChris.FillionR at 07:37, 13 June 2012

2012-06-13T07:37:28Z

JChris.FillionR at 07:36, 13 June 2012

2012-06-13T07:36:30Z

JChris.FillionR at 07:36, 13 June 2012

2012-06-13T07:36:07Z

JChris.FillionR: 4.0 -> 4.1

2012-04-12T04:44:55Z

4.0 -> 4.1

New page

A logic is a collection of "algorithms" that mainly process MRML nodes within a scene.
Logics can be:
* ''active'': observe the scene and nodes to react when receiving events are fired
* ''passive'' (helper): collection of utility functions to simplify the handling of nodes (e.g. <code>AddArchetypeVolume</code> in Volumes logic, Application logic.)
* a mix of both: not ideal.

There are 5 types of logics within Slicer. Their role is usually dictated by their dependencies. The [http://slicer.org/doc/html/classvtkMRMLAbstractLogic__inherit__graph.png inheritance graph] can be useful to understand the relationship between each logic types.
# '''MRML logics'''
#: Location
#:: ''Slicer4/Libs/MRML/Logics''
#: Dependencies
#:: MRMLCore
#:: no graphical dependency
#:: no Slicer dendendency (can by used by other projects)
#: Role
#:: Contain the base classes for logics (<code>vtkMRMLAbstractLogic</code>, <code>vtkMRMLApplicationLogic</code>) and helper classes
#:: MRML logics don't have access to the application, and so shouldn't contain any Slicer specific code.
#: Examples:
#::* factories: for MRML nodes (<code>vtkMRMLColorLogic</code> creates default <code>vtkMRMLColor*Nodes</code>)
#::* helpers: <code>vtkMRMLModelHierarchyLogic</code>
# '''Slicer Logics'''
#: Location
#:: ''Slicer4/Base/Logics''
#: Dependencies
#:: MRMLLogic
#: Role
#:: Specialization of '''MRML Logics''' for the Slicer application.
#: Examples:
#::* <code>vtkSlicerColorLogic</code>: knows about the "application" default LUT IDs and custom application lut files.
# '''Application logics'''
#: Location
#:: ''Slicer4/Libs/MRML/Logics/vtkMRMLApplicationLogic.[h|cxx]'' and ''Slicer4/Base/Logics/vtkSlicerApplicationLogic.[h|cxx]''
#: Dependencies
#:: <code>vtkMRMLApplicationLogic</code> doesn't depend about Slicer however <code>vtkSlicerApplicationLogic</code> does.
#: Role
#:: Contains application specific information. <code>vtkMRMLApplicationLogic</code> is an abstract class that is specialized for the application using MRML (<code>vtkSlicerApplicationLogic</code> for Slicer)
#:: <code>vtk[MRML/Slicer]ApplicationLogic</code> is NOT a singleton, however, it can be accessed by any logics (see <code>vtkMRMLAbstractLogic::SetApplicationLogic</code>) so it can be considered as such. It currently contains a list of nodes/logics, unique in the application. It is here for historic reasons (Slicer3), but it should not be seen as a placeholder for everything. Querying a module to get its logic should be preferred to access logics.
# '''Module logics'''
#: Location
#:: ''Slicer4/Modules/Loadable/XYZ/Logic/vtkSlicerXXXLogic''
#: Dependencies
#:: Slicer logics, XYZ nodes and optionally other module logics
#: Role
#:: A module logic is the module public API. While a module has typically (not necessarily) an associated widget/panel, no processing should be done within the widget, the widget is just the interface between the user and the logic/nodes. Modules can access other module logics (i.e. <code>qSlicerCoreApplication::moduleManager()->module("Volumes")->logic()</code>) if needed. There is maximum 1 module logic per module, however, it doesn't prevent the module logic to use helper logics (<code>vtkSlicerModelsLogic can instantiate/use </code>vtkMRMLModelHierarchyLogic</code>).
# '''Displayable managers'''
#: Location
#:: ''Slicer4/Libs/MRML/DisplayableManager''
#: Dependencies
#:: MRMLLogic and vtkRendering
#: Role
#:: They are logics that focus on representing nodes in a VTK renderer and handling user interaction within the view.
#:: Theoretically the slice logics should be displayable managers ( however, it might be a huge effort for just the sake of being consistent ).
#:: Displayable managers contain some limitations:
#:::* there is no control (yet?) over their creation, and once instantiated, it's not easy to control their behavior (properties can't be set externally on displayable managers).
#:::* they are not (yet?) well designed to communicate with each others.

A class (logic, widget...) should explicitly expose in its API the required logic(s) (e.g. <code>qMRMLColorPickerwidget::setColorLogic(vtkMRMLColorLogic*)</code>) instead of hiding the requirements by directly using the application logic (e.g. <code>this->GetApplicationLogic()->GetModelHierarchyLogic()</code> ).

It is the role of the class instantiator to pass the required logics to the created class (e.g. the module plugin sets the module logic to the module widget). For module logics depending on other module logics, it is resolved in the <code>qSlicer*Module::setup()</code> function, <code>qSlicer*Modules</code> have access to all modules and their logics that way (i.e. <code>qSlicerCoreApplication::moduleManager()->module("Volumes")->logic()</code>).
Exposing the requirements in the API instead of using singleton has the advantage of having a scope well defined and contained, the code becomes more modular and easier to unit test.

← Older revision		Revision as of 07:21, 14 June 2013
Line 1:		Line 1:
		+	<noinclude>{{documentation/versioncheck}}</noinclude>
	A logic is a collection of "algorithms" that mainly process MRML nodes within a scene.		A logic is a collection of "algorithms" that mainly process MRML nodes within a scene.

@@ Line 22: / Line 22: @@
 #::* helpers: <code>vtkMRMLModelHierarchyLogic</code>
 <!-- --------------------------------- -->
-# '''Slicer Logics'''
+# '''Slicer logics'''
 #: Location
 #:: ''Slicer/Base/Logics''

@@ Line 49: / Line 49: @@
 #:: A module logic is the module public API. While a module has typically (not necessarily) an associated widget/panel, no processing should be done within the widget, the widget is just the interface between the user and the logic/nodes. Modules can access other module logics (i.e. <code>qSlicerCoreApplication::moduleManager()->module("Volumes")->logic()</code>) if needed. There is maximum 1 module logic per module, however, it doesn't prevent the module logic to use helper logics (<code>vtkSlicerModelsLogic</code> can instantiate/use <code>vtkMRMLModelHierarchyLogic</code>).
 <!-- --------------------------------- -->
-# '''[[Documentation/4.1/Developers/DisplayableManagers|Displayable managers]]'''
+# '''[[Documentation/{{documentation/version}}/Developers/DisplayableManagers|Displayable managers]]'''
 #: Location
 #:: ''Slicer/Libs/MRML/DisplayableManager''

@@ Line 36: / Line 36: @@
 #:: ''Slicer/Libs/MRML/Logics/vtkMRMLApplicationLogic.[h|cxx]'' and ''Slicer/Base/Logics/vtkSlicerApplicationLogic.[h|cxx]''
 #: Dependencies
-#:: <code>vtkMRMLApplicationLogic</code> doesn't depend about Slicer however <code>vtkSlicerApplicationLogic</code> does.
+#:: <code>vtkMRMLApplicationLogic</code> doesn't depend on Slicer however <code>vtkSlicerApplicationLogic</code> does.
 #: Role
 #:: Contains application specific information. <code>vtkMRMLApplicationLogic</code> is an abstract class that is specialized for the application using MRML (<code>vtkSlicerApplicationLogic</code> for Slicer)

@@ Line 10: / Line 10: @@
 # '''MRML logics'''
 #: Location
-#:: ''Slicer4/Libs/MRML/Logics''
+#:: ''Slicer/Libs/MRML/Logics''
 #: Dependencies
 #:: MRMLCore
@@ Line 24: / Line 24: @@
 # '''Slicer Logics'''
 #: Location
-#:: ''Slicer4/Base/Logics''
+#:: ''Slicer/Base/Logics''
 #: Dependencies
 #:: MRMLLogic
@@ Line 34: / Line 34: @@
 # '''Application logics'''
 #: Location
-#:: ''Slicer4/Libs/MRML/Logics/vtkMRMLApplicationLogic.[h|cxx]'' and ''Slicer4/Base/Logics/vtkSlicerApplicationLogic.[h|cxx]''
+#:: ''Slicer/Libs/MRML/Logics/vtkMRMLApplicationLogic.[h|cxx]'' and ''Slicer/Base/Logics/vtkSlicerApplicationLogic.[h|cxx]''
 #: Dependencies
 #:: <code>vtkMRMLApplicationLogic</code> doesn't depend about Slicer however <code>vtkSlicerApplicationLogic</code> does.
@@ Line 43: / Line 43: @@
 # '''Module logics'''
 #: Location
-#:: ''Slicer4/Modules/Loadable/XYZ/Logic/vtkSlicerXXXLogic''
+#:: ''Slicer/Modules/Loadable/XYZ/Logic/vtkSlicerXXXLogic''
 #: Dependencies
 #:: Slicer logics, XYZ nodes and optionally other module logics
@@ Line 51: / Line 51: @@
 # '''[[Documentation/4.1/Developers/DisplayableManagers|Displayable managers]]'''
 #: Location
-#:: ''Slicer4/Libs/MRML/DisplayableManager''
+#:: ''Slicer/Libs/MRML/DisplayableManager''
 #: Dependencies
 #:: MRMLLogic and vtkRendering

@@ Line 1: / Line 1: @@
 A logic is a collection of "algorithms" that mainly process MRML nodes within a scene.
 Logics can be:
 * ''active'': observe the scene and nodes to react when receiving events are fired