I would like to be able to save/restore data from one usage session to another for my scripted python module. I understand that there is the ability to use a vtkMRMLScriptedModuleParameterNode()
like shown here. However, as far as I can tell, all this allows saving is strings as parameters, and I have moderately complex derived data that I would like to save/restore. This data is currently represented in python in nested dictionaries with entries which are objects that are custom classes (which are defined within my module file). Would the recommended approach be to just serialize these objects into strings and put them into the parameter node? If so, are there limits to how big the parameter node values could be (e.g. number of characters or number of bytes)? Alternatively, am I better off saving the data in some custom format to a file and then having a button to load from that file? I appreciate any recommendations people have, thanks!
It really depends on exactly how heavyweight your data ends up being and how granular you need to be in responding to events. For even medium complexity you can often get by with just json strings stored in a node attribute, like here. You are unlikely to hit a limit on the size of these (they are std::string
under the hood). It’s more performance that you would be concerned with. I suppose you can also pickle your custom python objects into these node attributes too.
If your json is more than a few hundred characters then it may be more appropriate to store it in a slicer.vtkMRMLTextNode
:
- You have the option to save the text in a separate file (so that you can view/edit more easily in external software).
- There is a separate
TextModifiedEvent
for indicating text content modifications - “Texts” module has a small text editor
- You can show/edit the content of the text node in your module using
slicer.qMRMLTextWidget
You can keep using the scripted module node for other parameters and add a node reference to the text node to store the json text.
Thanks for this suggestion and information @pieper. My data is more than short strings, but less than extremely huge (currently ~ 10K characters serialized into json), so probably either of these approaches would work. I am going to try the TextNode approach suggested by @lassoan because the ability to inspect/modify the contents easily within Slicer’s GUI may be handy during development.