Documentation/Labs/CLIInfrastructureCleanupAndRefactoring - Revision history

JChris.FillionR: /* Motivation */

2015-07-17T17:50:51Z

Motivation

JChris.FillionR at 17:49, 17 July 2015

2015-07-17T17:49:32Z

JChris.FillionR at 17:48, 17 July 2015

2015-07-17T17:48:56Z

JChris.FillionR: Created page with '= Motivation = See = Features = * TODO = Design and implementation = * TODO = Slicer core changes = * TODO = Future features = * TODO = Issues = * TODO = Topics to discuss…'

2015-07-17T17:32:41Z

Created page with '= Motivation = See = Features = * TODO = Design and implementation = * TODO = Slicer core changes = * TODO = Future features = * TODO = Issues = * TODO = Topics to discuss…'

New page

= Motivation =
See

= Features =
* TODO

= Design and implementation =
* TODO

= Slicer core changes =
* TODO

= Future features =
* TODO

= Issues =
* TODO

= Topics to discuss =
* TODO

= Notes =
* TODO

@@ Line 3: / Line 3: @@
 The current approach does not scale and is becoming more and more complex to manage and maintain:
-* https://github.com/naucoin/Slicer/commit/3e6845ee1fa13212b97f0b4155c6f6c2c81d04c2#commitcomment-12229331
+* [https://github.com/naucoin/Slicer/commit/3e6845ee1fa13212b97f0b4155c6f6c2c81d04c2#commitcomment-12229331 Andras comment of July 17th 2015]
 The plan would be to generalize the infrastructure so that:
 * module can easily register new type of CLI output and input
 * module UI generation leverage CTK CLI infrastructure
-−
+*
 = Features =

@@ Line 2: / Line 2: @@
 The current [https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.h CLI logic] and [https://github.com/Slicer/Slicer/tree/master/Base/QTCLI associated GUI classes] consists of complex set of hardcoded check to handle different type of MRML node. It is nearly impossible for extension to extend the existing mechanism and support other type of input and output for new [[Documentation/Nightly/Developers/Modules#Command_Line_Interface_.28CLI.29|CLI modules]]. For core module extending the infrastructure, the current approach is to copy the MRML node into MRML/Core directory.
-The current approach does not scale and is becoming more and more complex to manage and maintain.
+The current approach does not scale and is becoming more and more complex to manage and maintain:
 The plan would be to generalize the infrastructure so that:

@@ Line 1: / Line 1: @@
 = Motivation =
-See
+The current [https://github.com/Slicer/Slicer/blob/master/Base/QTCLI/vtkSlicerCLIModuleLogic.h CLI logic] and [https://github.com/Slicer/Slicer/tree/master/Base/QTCLI associated GUI classes] consists of complex set of hardcoded check to handle different type of MRML node. It is nearly impossible for extension to extend the existing mechanism and support other type of input and output for new [[Documentation/Nightly/Developers/Modules#Command_Line_Interface_.28CLI.29|CLI modules]]. For core module extending the infrastructure, the current approach is to copy the MRML node into MRML/Core directory.
 = Features =
@@ Line 9: / Line 16: @@
 = Slicer core changes =
-* TODO
+* Some preliminary work (in both CTK and Slicer) has been done to reuse the CTK CLI infrastructure. It would have to be rebased against a current master:
 = Future features =