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
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 PackageChecked 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/ParameterChangein the Plugin Framework that may be limiting the standardization and efficacy ofPluginParameterextensions and may cause some issues down the track.It looks like
ParameterTypeimplementations should utilise a map from thePluginParameterthat they are contained within, to store data related to theParameterTypethat is not the data represented by theParameterValue. A good example of where this is being done well would be in theStringParameterType.setLinesfunction. A good example of where this could be fixed would be in theFileParameterTypewhere theFileParameterValueshould only represents a list of files. Currently theFileParameterValuerepresents the list of files, the file input kind, the file filter, the accept all file filter flag.By controlling these attributes at the
ParameterValuelevel, theParameterChangemechanism is not utilised. Meaning that anyPluginParameterListenerto this instance of aPluginParameter<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.PROPERTYflag and can react accordingly.This ticket proposes that all PluginParamerter implementations be reviewed and refactored so that any attributes related to a
PluginParameterValuethat do not represent the data of that value be stored in thePluginParameteroptions attribute to better utilise thePluginPrameterListenerframework by being moved and stored as aPluginParameterproperty.Known Examples include:
FileParameterValueFloatParameterValueIntegerParameterValueMultiChoiceParameterValueSingleChoiceparameterValueSteps 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