Difference between revisions of "2013 Project Week:SimplifyMRMLReference"

From NAMIC Wiki
Jump to: navigation, search
Line 31: Line 31:
 
* A more general MRML node reference architecture were proposed and discussed.
 
* A more general MRML node reference architecture were proposed and discussed.
 
* Reference node API should be developed in the base vtkMRMLNode including:
 
* Reference node API should be developed in the base vtkMRMLNode including:
** creating reference and managing references for a particular category, for example "displayNode" or "transformNode".  
+
** creating and managing references for a particular category, for example "displayNode" or "transformNode".  
 
** managing references together with observers and events
 
** managing references together with observers and events
 
* Alex created a github topic branch with the prototype API:
 
* Alex created a github topic branch with the prototype API:
 
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch
 
https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch
 +
* Success criteris: implementation of vtkMRMLDisplayableNode should utilize new reference API and the tests associated with it should still pass.
 +
  
 
</div>
 
</div>

Revision as of 21:50, 8 January 2013

Home < 2013 Project Week:SimplifyMRMLReference

Key Investigators

  • Isomics: Alex Yarmarkovich, Steve Pieper
  • Andras Lasso
  • Kitware: Julien Finet, Jean-Christophe Fillion-Robin

Objective

Slicer4 MRML node referencing mechanism needs some design improvement, as for each referenced node in each node type about 10 methods shall be added/updated manually. This is very difficult to do, often done incorrectly. The goal is to discuss the details and design robust, simple, centralized implementation of all node reference updates for save/load, undo/redo, scene import features

Approach, Plan

A potential solution would be to introduce a "ReferencedNodes" list, which would store pointer, ID string, node type name, and observers for each referenced node instead of adding separate member variables for these manually. This list could be fully maintained by the Copy, UpdateScene, UpdateReferenceID, UpdateReferences, ReadXMLAttributes, WriteXML, etc. methods implementation in vtkMRMLNode base class. Developers would just need to add an item to the ReferencedNodes list and all the rest would be handled by the MRML framework.

Progress

  • Design meeting held on 01/08/2013: Yarmarkovich, Steve Pieper, Andras Lasso, Julien Finet, Jean-Christophe Fillion-Robin
  • A more general MRML node reference architecture were proposed and discussed.
  • Reference node API should be developed in the base vtkMRMLNode including:
    • creating and managing references for a particular category, for example "displayNode" or "transformNode".
    • managing references together with observers and events
  • Alex created a github topic branch with the prototype API:

https://github.com/ayarmarkovich/Slicer/tree/mrml_ref_branch

  • Success criteris: implementation of vtkMRMLDisplayableNode should utilize new reference API and the tests associated with it should still pass.


Delivery Mechanism

This work will be delivered to the NA-MIC Kit as changes in the Slicer4 core and in the SlicerRT extension


References