More flexible UI generation

[ctrueden]

• Need a way to customize WidgetModel rather than hardcoding its creation. In particular, KNIME needs a WidgetModel/SettingsModel combo object for each input.
• Need a way to customize creation of the input harvester dialog, in general. This should not be embedded in the preprocessing logic, but rather be a general-purpose "make me an InputPanel" or similar. Consider changing the name, too, since this is useful for more than just "input harvesting".

This work may entail substantial changes to WidgetService and maybe UIService as well as the possible creation of new service(s). (Personally I think we won't need as many new services as @Squareys outlines below, but the point is that the functionality needs to go somewhere.)

---

Original description from @Squareys and @dietzc:

Current Solution

Custom WidgetService wraps widgets from SwingWidgetService in a WrappingKnimeDialogInputWidget which basically is just the widget plus a SettingsModel from a SettingsModelService. An InputHarvester is instantiated to generate UI from a Module on an InputPanel, which is manually created with a SwingWidgetService.

Preferred Solution

UIGenerationService creates InputPanel and UI from Module(Info) using a WidgetService. WidgetServices require WidgetModels per Inputs, which are created via a WidgetModelService. A custom KnimeWidgetModelService creates WidgetModels which store values in SettingsModels instead of Module inputs. Our dialog as well as the InputHarvester generate UI from the UIGenerationService.

Summary of Requirements for Preferred Solution

• Service for generating UI from Module(Info)s
• Service for WidgetModel creation from Modules
• Interface/AbstractClass for WidgetModels

ModuleInfo would be more fit for our cast, but I think impossible for the ImageJ case, since current WidgetModel stores values in inputs of executing module.

[ctrueden]

1. Extract interface from WidgetModel. Rename the current WidgetModel concrete implementation to DefaultWidgetModel.
2. Add createModel method to WidgetService; always use it instead of new WidgetModel.
3. Create a KNIMEWidgetModel which extends DefaultWidgetModel and includes a SettingsModel.
4. Create a KNIMEWidgetService and overwrite createModel to create a KNIMEWidgetModel instead of a DefaultWidgetModel.

We want to avoid the need for an ExtendedInputPanel. So after the above, it should be possible to refactor this class away. And if not, we will examine further why not.

[ctrueden]

Progress (1 and 2 done) on master branch of scijava-common. You're welcome!

[ctrueden]

Since the remaining tasks are on the KNIME side, I am closing this issue. Please reopen if anything further is needed on the SciJava Common side!