Module inputs resolvable only within module preprocessing are populated in user dialogs

[PetrBainar]

Using the REST API, ImageJ server provides information on all available modules as well as particular module inputs which need to be harvested.

However, some of the inputs can be resolved only within the module pre-processing and listing them in a user dialog is therefore superfluous and confusing.

It would be great to determine whether a parameter is resolvable and sent information on its resolvability together with other module input details to the client. Resolvable inputs then might not be populated in a user dialog. We still want to populate some resolvable inputs like active images, user-preferences and last-used values.

[PetrBainar]

Branch created: https://github.com/imagej/imagej-server/compare/better-module-details

[ctrueden]

@PetrBainar Is the better-module-details branch completed and working? Or still roadblocks? If so, what still needs to be done?

[PetrBainar]

@ctrueden Yes, it seems working as intended, we are able to find out whether a given module input can be resolved. I would like to ask you, if you can check the implementation from the system architecture point of view. For example, the design is tailored to Commands and would not work with more general Modules, even though it leans on, among others, ModuleService.

If you find it satisfactory, together with addressing your feedback I will add few more comments, method annotations etc. and create a merge request.

[PetrBainar]

Just read this CellProfiler pull request.

The current implementation still returns the resolvable input, but it also provides the isResolved flag so that the client can decide what to do with it. For example, the Command net.imagej.plugins.commands.imglib.RotateImageXY would return information on the Context input as follows:

input ModuleItem	value
name	"context"
label	""
isResolved	true
startingValue	"object:jftfgbj72sdcpjb1"
genericType	"class org.scijava.Context"
defaultValue	null
required	true
widgetStyle	""
choices	null
stepSize	null
minimumValue	null
maximumValue	null
columnCount	6
softMinimum	null
softMaximum	null

The startingValue information can be useful for populating values which were used last time. See the Angle input from the same Command as an example:

input ModuleItem	value
name	"angle"
label	"Angle"
isResolved	false
startingValue	22
genericType	"double"
defaultValue	0
required	true
widgetStyle	""
choices	null
stepSize	null
minimumValue	null
maximumValue	null
columnCount	6
softMinimum	null
softMaximum	null

[ctrueden]

@PetrBainar With the merge of #18, can this issue be closed? Or is there more to do?

[PetrBainar]

An undesired behaviour has been observed, there is a fix for that in #28.

[PetrBainar]

The undesired behaviour has been fixed, closing the issue.