How can i define the order of components I/O like double components? this has been a long standing issue that in the end somewhat worked with quickforms and now it’s broken again?
Hi,
could you elaborate on what do you mean by “How can i define the order of components I/O like double components?”. What are double components? And what was the solution before? A minimal example workflow of what you would want to achieve would be very helpful.
Best regards,
Misha
Mixed up terminology. I meant the new configuration nodes in the new Component “nodes”.
As far as i can tell I can only make a layout with widget but not configurations? Also widgets are only available in webportal while configurations are like the former quick nodes except you can’t specify an order? (And do they work on web portal?).
I’m having trouble to see the advanatge of this change and how to use the new nodes over quick forms.
In short, Configuration nodes are used to parametrize workflow and appear in the component configuration dialog (the one that opens on F6 or double-click on a component), while Widget nodes are used to define interactivity in the workflow and they appear on the WebPortal/Interactive View (the one that opens on F10 or right click->Interactive View). So the functionality of the deprecated quickforms is split between these two new node categories.
Let me answer your questions one-by-one:
As far as i can tell I can only make a layout with widget but not configurations?
The layout of the WebPortal/Interactive View is fully customizable and is filled with Widgets only. The layout of elements in the component configuration dialog can not be modified in KNIME 4.0 and is filled with Configurations only. In this respect the situation does not change wrt deprecated quickforms, if you imagine a quickform as a combination of a new Configuration and the corresponding Widget.
Also widgets are only available in webportal while configurations are like the former quick nodes except you can’t specify an order? (And do they work on web portal?).
Yes, widgets appear only on the WebPortal/Interactive View, but Configurations correspond only to a fraction of old quickform functionality (quickforms appeared on WebPortal, while Configurations don’t).
I’m having trouble to see the advanatge of this change and how to use the new nodes over quick forms.
In the past quickforms served 3 purposes: parametrisation, interactivity and parameters in REST calls. These functionalities were split now between nodes
There will be a webinar on the new features in KNIME 4.0 on July, 25 and everyone is invited to join to get a better overview of how new add-on’s work: Events| KNIME
6 Likes
Thanks for the explanations.
I still however fail to see the advanatge an I fear it will make things more complicated. We have shared wrapped nodes with quickforms which could be used either on the server/webportal or on the client.
it seems these nodes now need to be duplicated or one needs to use the views to configure them which is much, much slower. And i can only configure using views after running the component which makes no sense? I want to configure it and then run it.
This splitting up probably makes sense in the code bu from a user perspective, it’s as far as I can tell a mess.
1 Like
Hi @beginner,
Sorry to hear that. Any chance that you quickly explain one or two use-cases where you want to configure a node from within KNIME Analytics Platform and in the WebPortal? Do you configure the node in KNIME AP mainly during debugging?
Thanks!
Christian
2 Likes
Hi Christian,
prepare for rant…
a lot plays into this and maybe I’m just a bit grumpy and “anti-change” and have yet to get the advantages of the new setup. What bothers me is that every other version gets a new way to make the configs. First there were the quick forms, then new quick forms nodes and now we have a complete change. Each time this changes every single workflow needs to be manually adjusted. It’s a maintenance nightmare with limited added value.
Now to the actual splitting of the functionalities. We have wrapped nodes for some common tasks. They can be used locally and on the web portal. With this change we either need 2 versions or use the widget based one also locally. Using widget one locally doesn’t really work as you first need to run the node (so it’s green) to be able to reconfigure it. Then you reconfigure and run it again. For longer running components this obviously is an issue. For fast running ones, the widget dialog is just too slow to load especially if you want to play around quickly. Waiting at least 3 seconds for every single adjustment is annyoing. Loading that dialog faster should be a top priority.
Also why are the configurations limited in their naming? value_1 or value1 is forbidden? This is an allowed value in a JSON key, a query string, as a java variable etc. It’s completely obscure why this should not be allowed, it looks like some weird knime special sauce…which doesn’t help with my confidence in this new system (maybe I’m missing something but that is my first impression).
Now not only need I replace quick forms with configurations / widgets, in some cases the variable names need to be changed meaning the actual nodes using it also need to be changed.
And what also puzzles me is that I wonder were this idea came from and why it was never even raised to the community and customers (Or did I miss it?). Just a big change coming out of nowhere (for me). Yeah I see the design in the web portal was limited but it’s not used for fancy manager dashboards. There are other products for that and visualizations simply aren’t KNIMEs strengths and really good ones can’t be automated anyway.
I understand you want to sell your product and fancy visualizations help with that but for me as advanced user and admin it only adds maintenance overhead and little to no value. I have better things to do than style a web portal entry form (meaning I won’t use that new option) and I haven’t heard a single user complain about the looks of the web portal. hence that big change for me really came out of the blue.
3 Likes
(Thanks for the extensive reply!)
Let me chime in here. It seems your post deserves two answers: background infos on why we chose to split the nodes, and comments on the “problems” that you report.
As for the former, one of the strong drivers for the separation is that it’s much closer to what you know from native KNIME nodes where there is a configuration (dialog) and a view and these two sets of nodes highlight that fact. In depends on the context where you use these components. Do you use the components via the web portal (or composite view) or do you use them as re-usable entities shared via server or “LOCAL” workspace (a feature not only relevant for server users). Apparently you use them for both and we believe that’s not the standard use case (though it’s still supported – chain the nodes and you will have the same functionality). Admittedly that’s slightly more complicated but we are willing to accept that given that both the standard cases are now easier and more approachable for the average user. (You probably read this already – it provides some more background on components and the new node sets.)
Regarding the problems/questions:
-
The sluggish response opening the view/widget: It varies greatly on the system you are running it on. On mine it opens in << 1s (yeah, developer answer!). We are aware of performance issues especially on Windows. We and working on it (diagnosing it). It seems the problem gets much worse if Windows Defender is intercepting (we are in contact with Microsoft on this) and we do more research on where other bottlenecks are.
-
value_1 vs. value1 vs. value-1: Since this fields can be controlled via flow variable (on the component) the identifiers need to be unique across the component (think of two nodes using the same variable name). The framework enforces that by appending the node id to the identifier in the flow var tab.
6 Likes
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.