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 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 ofPluginParameter
extensions and may cause some issues down the track.It looks like
ParameterType
implementations should utilise a map from thePluginParameter
that they are contained within, to store data related to theParameterType
that is not the data represented by theParameterValue
. A good example of where this is being done well would be in theStringParameterType.setLines
function. A good example of where this could be fixed would be in theFileParameterType
where theFileParameterValue
should only represents a list of files. Currently theFileParameterValue
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, theParameterChange
mechanism is not utilised. Meaning that anyPluginParameterListener
to 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.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 thePluginParameter
options attribute to better utilise thePluginPrameterListener
framework by being moved and stored as aPluginParameter
property.Known Examples include:
FileParameterValue
FloatParameterValue
IntegerParameterValue
MultiChoiceParameterValue
SingleChoiceparameterValue
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