The pure-Python node that I am developing on KAP v4.7 has quite a number of configuration parameters. Since not all of them are always required, I would like to guide the user by displaying only the relevant ones in the dialog depending on his selections. The irrelevant ones may be either greyed out, i.e., blocked for entry, or hidden from the configuration dialog.
As examples, think of the String Manipulation node and its column replace/append option or the String Replacer’s append column checkbox plus text field.
The Python API documentation does not seem to cover this precise use case. Are conditional configuration parameters achievable?
If yes, please guide me with a small example that uses
Parameters
Parameter Groups (if any difference in making them conditional exists)
If not, please let me know if and where it is on your roadmap.
Very good point, this is functionality we have on our roadmap for the pure-Python node API but it is not available yet unfortunately.
For the time being, you could mark some of the options as is_advanced=True and mention in the node description that the user can configure more details by clicking “show advanced settings”?
Once we have the API for conditional parameters you could remove the is_advanced flag. This will be a backwards compatible change to your node, meaning it only influences the dialog and not how the parameters are stored.
Could you provide a little more details on the following:
Where exactly is it supposed to be set? I have not seen it in the tooltips. Is it an undocumented argument of the parameter classes?
Is it available for all parameter types?
Is it compatible with parameter groups?
As I did not know that basic vs. advanced parameters were a feature of the Python API, I believe I need to rephrase the explanation of my use case:
My node uploads data to a cloud API service. I want to give the user the possibility to choose whether he wants to create a new dataset or change an already existing one. While some parameters are the same (e.g., username, password), others differ depending on that. For instance, a new dataset must be given a name, but to modify an existing one, the user must instead provide its unique ID, which is generated by the service upon creation.
Since the code for both cases is 95% the same, I don’t want to split these functionalities into separate nodes.
Initially, I therefore thought about doing something like in the simplified snippet below, but I guess that the validators are only triggered when the user clicks on “OK” or “Apply” in the configuration dialog (much like with the validation options of the configuration nodes for components), right?
class DataUpload:
upload_mode = knext.StringParameter(
label="Upload Mode",
enum=["New", "Modify"]
)
@upload_mode.validator
def validate_upload_mode(self, value):
match value:
case "New":
self.name = knext.StringParameter(label="Dataset Name")
case "Modify":
self.id = knext.StringParameter(label="Dataset ID")
def configure(self, config_context):
pass
def execute(self, exec_context):
pass
And I totally get your use case, we have a plan for how to realize the conditional parameters already but due to other priorities could not finish it for the 5.1 release. Then it will be able to only show/hide certain parameters based on the value of other parameters.
As for the validators: correct, the Python methods are only called on “Ok”. The min and max values of numeric parameters (see API docs) are already enforced in the UI elements though.
Dynamically modifying the parameters in a validator like in your code snippet is an interesting idea. Definitely not what we had in mind when building the API And it would probably cause problems when saving/loading the node because it would not load the value of name or id if the validator hasn’t run before. So… I suggest not to do that
You are right – and I already figured that the dynamic modification of parameters in a validator would not have been the safest path to choose.
If it works at all, my expectation from this somewhat creative implementation was that the user would make his selections, click on “OK”, and see some new configuration options pop up. Still not ideal though.
So, I am going to stop trying to find loopholes in the API and wait patiently until this feature is officially released.
And it would probably cause problems when saving/loading the node because it would not load the value of 