When I develop apps for the web portal, I’ll often want to check that the user selected valid combinations of options in a component. Currently, I have to create a companion validation component directly downstream of the original component just to alert the user if they chose invalid options.
My suggestion is to allow validation logic to be placed in the Component Output node. This way, when the user selects the “Next” button, the logic would be invoked and a custom error message can be displayed, preventing the workflow from continuing.
Note: I realize some widgets provide a certain amount of validation, but sometimes additional validation logic must be performed.
Given that there are endless ways to check the validation of the output of a component, I personally believe that your solution of controlling this logic via more nodes is way more flexible and powerful.
I would encourage you to share your validation component on the KNIME Hub for other to reuse.
If you want to make your nested component fail with a custom error I would encourage you to use a Breakpoint node. For validation you could also use Table Difference Finder or similar nodes.
Regarding the WebPortal itself if you do not want the workflow to fail with a custom error showing in the red footer, then you could use a Refresh Button Widget which says “Validate” and downstream a text output widget with the problem found in the validation triggered via a switch. To design data apps which refresh on the same component page check this workflow:
Thanks very much for the considered response. My apologies for the late reply, but I have been on vacation.
I think I understand your point about the power and flexibility of using a separate component for validation of the first component.
However I’ll do my best to try to persuade you that there are also significant problems with that approach.
But first allow me to briefly state my requirements. Almost all of the time I don’t need anything more than to check the values of variables from configuration or widget nodes to ensure the user entered valid combinations of values.
A simple scripting feature in the component output node that allows me to return an error string (if errors were found) or empty string (no errors found) for example, would suffice.
The main problems with supplying a companion component to perform validation are:
It defeats the encapsulation provided by components. A component should be self-contained, and validation is a critical part of that component.
Imagine every time I create a nice component, I have to instruct any users of the component not to forget to also download the companion validator component.
Furthermore, the validation component would always have to be kept in sync with the component it’s validating. The possibility of mismatching versions becomes a problem.
In order for the validation component to act on the variable values from the original component, those variables have to be leaked into the main workflow. Pretty soon we have a ton of variables that persist throughout the workflow although they’re only needed in their respective validation components.
My workflows are typically complex and consist of many components and thousands of nodes. Adding validation components just increases the complexity and size of my workflows (cluttering the workflows and making them slower to load).
I agree that in rare cases one might need more than to display an error message, and in those cases a companion validator component might be justified. At least for me, however, this most often would be overkill and problematic for the reasons mentioned above.
By the way, indeed I enjoy using the Refresh button (thanks for the suggestion), but I don’t want to have to rely on the user clicking the refresh button to validate the node. Validation should occur always whether or not the refresh button is clicked. Performing validation in the component output node would be simple and elegant (IMHO).
Thanks kindly, and please let me know if there’s something I’m overlooking.
This might be a dumb question, but is there a reason you’re not putting your validation component directly before the output of the configuration component?
Thank for taking the time to provide this extremely valuable feedback.
While the devs look into this we provide a few concepts which might make those issues less problematic. This does not mean we should not address your points, I am just proposing something that might make your life easier in the meantime.
- @Thyme is right. Using the validation component as a nested component will create this user journey:
The user uses the widget nodes, clicks next, an error shows on the webportal interface (which comes from the breakpoint node inside the validation component which is nested inside the next component with possibly more widget nodes). Then the user cannot proceed any further but he can go back and change the settings.
EDIT: apparently the validation component for this to work needs to be nested in the beginning of the next component not the same one, otherwise you cannot go back. we are investigating this. I am updating the workflow.
I uploaded the workflow here, please have a look:
- Depending on your use case you can avoid having a multi page application. As shown below and in this workflow, you can use the refresh button widget to define the steps within a single page. This works especially well with forms as you do not change page as more widgets appear in the same page. All the validation can work here regardless of what the next button does, as it is all in the same root component using nested components.
- With KNIME AP 4.5 we have for certain widgets new re-execution capabilities. Those are only some, not all of them, but we should expand this soon to all of them if the feature is popular. The idea is that as soon as you are done interacting with the widget this triggers automatically the workflow making the point 2 above even easier (as soon as the user is done interacting either an error shows up or the next widget is triggered via a switch node).
Those are the ones:
- Boolean Widget
- Column Selection Widget
- Column Filter Widget
- Multiple Selection Widget
- Nominal Row Filter Widget
- Single Selection Widget
- Value Selection Widget
Does any of this help?
Rest assured our devs are looking into the issues you are pointing out.
Thanks for your help!
I’m afraid you may be right. I tried to figure out a way to nest a validation component in the original component, and never came up with a satisfactory solution. Perhaps I’m not being clever enough(?). I’m very curious to see if you can come up with a nested component solution. Incidentally, my workflows need to be fairly polished, and a ‘workflow not executed’ message is not friendly enough, I’m afraid.
Your option 2 is good advice, generally, but my workflows tend to be multi-page in nature. I’m looking forward to upgrading to KNIME AP 4.5 to leverage re-execution based on event generation from selected widget nodes. I’m not sure it helps solve the validation issue, but it’s very welcome functionality.
By the way, my companion validation nodes tend to have this structure:
The original, upstream component emits an error variable indicating if an error occurred, and a String variable describing the error (if any). The If switch in this validation component evaluates the error variable. If there’s an error, a Text Output Widget shows an error message and instructs the user to go back to the previous page to fix the error, and the component outputs are inactivated so the user can’t proceed. If there’s no error, the input ports are passed through to the output ports and no error message is shown. This works on the desktop, but I haven’t been able to test it on the server yet.
Hi @dnaki ,
if you don’t want to show the WebPortal error with the breakpoint custom message then yes,
your option to deactivate ports is quite good.
I created a new example implementing a nested validation component and port deactivation.
I also added some data so it looks more realistic.
I tested in the WebPortal and it works.
Let me know if this helps.
You could but the “shared logic” of the validation component in a metanode instead (or actually it can stay a component) but take the text output widget out and put it in the “main component”. Yes this isn’t DRY. You will need to create the text widget output for each now share component. Annoying I agree. But I think it would solve your issue.