# Improving the exposure of \`vtkSlicerModuleLogic\`s to other components

**URL:** <https://discourse.slicer.org/t/improving-the-exposure-of-vtkslicermodulelogic-s-to-other-components/15375>\
**Category:** Development\
**Created:** [January 6, 2021, 11:18am UTC](https://discourse.slicer.org/t/improving-the-exposure-of-vtkslicermodulelogic-s-to-other-components/15375 "2021-01-06T11:18:02Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![RafaelPalomar](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rafaelpalomar/32/1436_2.png) [@RafaelPalomar](https://discourse.slicer.org/u/RafaelPalomar)\
**Post date:** [January 6, 2021, 11:18am UTC](https://discourse.slicer.org/t/improving-the-exposure-of-vtkslicermodulelogic-s-to-other-components/15375/1 "2021-01-06T11:18:02Z")

</div>

The purpose of this post is to frame the discussion around improving the exposure of `vtkSlicerModuleLogic`s to other Slicer components (e.g., displayable managers). After having a look at the code, my understanding of the **current situation** is as follows:

- Each `vtkSlicerModuleLogic` is created and kept by its corresponding `qSlicerModule`, as a member variable.
- A logic object can be obtained by the `qSlicerAbstractCoreModule::logic()` method or `qSlicerAbstractModuleRepresentation::logic()` (for module widgets).
- `vtkSlicerModuleLogic`s are very flexible components and it is desirable that they can be more easily exposed to other components (possibly in other modules).

The **plan for improving** the exposure of `vtkSlicerModuleLogic`s could be as follows:

- Keeping an association between `qSlicerModule`s and `vtkSlicerModuleLogic`s in **`vtkMRMLApplicationLogic`** , which is a more reachable component.
- Remove `qSlicerAbstractCoreModule::logic()` and `qSlicerAbstractModuleRepresentation::logic()`. For consistency, the only way to access the module logics will be `vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName)`.
- Lifecycle of `vtkSlicerModuleLogic`s will still be managed by `qSlicerModule`s. There will be only 1 logic per module.

@lassoan, @jcfr, @pieper, does it look to you like a good course of action?

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 6, 2021, 1:56pm UTC](https://discourse.slicer.org/t/improving-the-exposure-of-vtkslicermodulelogic-s-to-other-components/15375/2 "2021-01-06T13:56:39Z")

</div>

Thanks for working on this and for the detailed summary. Beside of one nitpick outlined below, it all makes sense.

> - Remove `qSlicerAbstractCoreModule::logic()` and `qSlicerAbstractModuleRepresentation::logic()` . For consistency, the only way to access the module logics will be `vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName)` .

I suggest we keep these.

The use of `vtkMRMLApplicationLogic::GetModuleLogic(const char* moduleName)` should be considered to access module logic from displayable managers/application code/scripts.

And I still think a module `Foo` should still access `FooLogic` using the existing accessors.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [January 7, 2021, 9:33pm UTC](https://discourse.slicer.org/t/improving-the-exposure-of-vtkslicermodulelogic-s-to-other-components/15375/3 "2021-01-07T21:33:21Z")

</div>

Yes, we shouldn’t remove the old API or we could break extensions. But having this extra non-gui method to access the logics sounds great.