Description
Prerequisites
-
Put an X between the brackets on this line if you have done all of
the following:-
Running the latest version of Constellation
-
Attached the Support Package via
Help>
Support Package -
Checked the FAQs:
https://github.com/constellation-app/constellation/wiki/FAQ -
Checked that your issue isn’t already filed:
https://github.com/constellation-app/constellation/issues -
Checked that there is not already a module that provides the
described functionality:
https://github.com/constellation-app/constellation/wiki/Catalogue-of-Repositories
-
Description
Just noting some deviation from (what I assume was) the intended use of PluginParameter / ParameterValue / ParameterType / ParameterChange in the Plugin Framework that may be limiting the standardization and efficacy of PluginParameter extensions and may cause some issues down the track.
It looks like ParameterType implementations should utilise a map from the PluginParameter that they are contained within, to store data related to the ParameterType that is not the data represented by the ParameterValue. A good example of where this is being done well would be in the StringParameterType.setLines function. A good example of where this could be fixed would be in the FileParameterType where the FileParameterValue should only represents a list of files. Currently the FileParameterValue represents the list of files, the file input kind, the file filter, the accept all file filter flag.
By controlling these attributes at the ParameterValue level, the ParameterChange mechanism is not utilised. Meaning that any PluginParameterListener to this instance of a PluginParameter<FileParameterType> is not notified of changes to the file filter, file kind and accept all attributes.
Instead if these attributes were captured as properties, listeners would automatically be notified with a ParameterChange.PROPERTY flag and can react accordingly.
This ticket proposes that all PluginParamerter implementations be reviewed and refactored so that any attributes related to a PluginParameterValue that do not represent the data of that value be stored in the PluginParameter options attribute to better utilise the PluginPrameterListener framework by being moved and stored as a PluginParameter property.
Known Examples include:
FileParameterValue
- private FileParameterKind kind;
- private ExtensionFilter filter;
- private boolean acceptAllFileFilterUsed;
FloatParameterValue
- private Float min;
- private Float max;
- private Float step;
IntegerParameterValue
- private Integer min;
- private Integer max;
- private Integer step;
MultiChoiceParameterValue
- private final List options;
- private final Class<? extends ParameterValue> innerClass;
SingleChoiceparameterValue
- private final List options;
- private final Class<? extends ParameterValue> innerClass;
Steps to Reproduce
N.A
Behaviour
N/A
Additional Information
An Example of correcting one of these mis-stored properties can be seen with the refactor of the FileFilter in the FileParameter Value in PR #2025
Activity