Module details should return type information

[mcquin]

Currently there isn't a way to infer type information from the details response.

We need type information to render the appropriate form elements inside a CellProfiler module.

[ctrueden]

The genericType key should give you what you need. It returns the toString() representation of the Java type (class or interface). E.g.:

$ curl localhost:8080/modules/'command:org.scijava.plugins.commands.debug.SystemInformation'|json_pp|sed 's/^ \{9\}\("genericType"\)/=======> \1/'
{
   "inputs" : [
      {
         "required" : true,
         "label" : "",
         "defaultValue" : null,
         "stepSize" : null,
         "name" : "context",
=======> "genericType" : "class org.scijava.Context",
         "widgetStyle" : "",
         "columnCount" : 6,
         "choices" : null,
         "minimumValue" : null,
         "softMinimum" : null,
         "maximumValue" : null,
         "softMaximum" : null
      },
      {
         "required" : true,
         "label" : "",
         "defaultValue" : null,
         "stepSize" : null,
         "name" : "appService",
         "widgetStyle" : "",
=======> "genericType" : "interface org.scijava.app.AppService",
         "maximumValue" : null,
         "softMinimum" : null,
         "minimumValue" : null,
         "choices" : null,
         "columnCount" : 6,
         "softMaximum" : null
      },
      {
         "required" : true,
         "label" : "",
         "defaultValue" : null,
         "stepSize" : null,
         "name" : "statusService",
         "widgetStyle" : "",
=======> "genericType" : "interface org.scijava.app.StatusService",
         "maximumValue" : null,
         "softMinimum" : null,
         "choices" : null,
         "minimumValue" : null,
         "columnCount" : 6,
         "softMaximum" : null
      },
      {
         "widgetStyle" : "",
=======> "genericType" : "interface org.scijava.log.LogService",
         "name" : "log",
         "softMaximum" : null,
         "choices" : null,
         "columnCount" : 6,
         "minimumValue" : null,
         "maximumValue" : null,
         "softMinimum" : null,
         "label" : "",
         "required" : true,
         "stepSize" : null,
         "defaultValue" : null
      }
   ],
   "identifier" : "command:org.scijava.plugins.commands.debug.SystemInformation",
   "outputs" : [
      {
         "widgetStyle" : "",
=======> "genericType" : "class java.lang.String",
         "name" : "info",
         "softMaximum" : null,
         "maximumValue" : null,
         "softMinimum" : null,
         "columnCount" : 6,
         "choices" : null,
         "minimumValue" : null,
         "label" : "System Information",
         "required" : true,
         "stepSize" : null,
         "defaultValue" : null
      }
   ]
}

[0x00b1]

@ctrueden Awesome! Do you happen to have a list of possible types? Likewise, are they documented somewhere (e.g. class org.scijava.Context)?

[ctrueden]

@0x00b1 The types are Java types, so the list is necessarily open-ended. On the CellProfiler side, I think it would be sufficient to just have a big hunk of case logic for all the types you support, and then you can error out—or better, have catch-all generic logic—if the module has any unsupported types.

For possible catch-all logic, it could make sense if users could connect the output of one module to the input of another as long as the types match. It could also make sense to simply let the user type something in a text box, which the ImageJ server would then try to coerce into the proper type via the SciJava conversion framework (i.e., not CellProfiler's problem).

A bunch of the common types are illustrated in Widgets.js. That does not include image types, though:

• net.imagej.Dataset
• net.imagej.ImgPlus
• net.imglib2.RandomAccessibleInterval
• net.imglib2.IterableInterval
• net.imglib2.img.Img

And there are also tables in net.imagej.table.Table and subtypes. And in the future: a ton of ROI types too.

As for the Context and Service types: you can and should leave those null/unpopulated, since the framework will fill them in for you.

I realize that it sucks to have to hardcode a bunch of cases like that though, so in the future, perhaps we should add an automagical type simplification layer, and/or simpleType field to the details, which says more Python-friendly things like number or image. What would make your life easier here?