Dependent Quickforms


One of the amazing things in Knime is to bundle several steps into Meta/Subnodes - to hide complexity and provide easy config interfaces via Quckforms.
Frequently, I have situations where the value provided in the first quickform would impact what would be available as choices in the 2nd quickform. (= there are a few additional nodes after the first quickform preparing the choices for the 2nd quickform). 

To date, I think the only way to make this work is to select the value in the first quickform, then execute the node, then go back to the config dialog and set the 2nd  quickform value.

Is there any way of creating a dependency between quickforms - making it execute the subsequent nodes upon value change?

(One way could be to create an "Execute" Quickform that would just expose a button in the config dialog - and upon pushing that, it would execute itself (doing onthing) and all its dependent nodes. Tried to do that - but failed to see how to envoke an execute. Maybe you could give me a hint?)




I tried to proceed a bit on the idea of a "Execute Workflow to this node" quckform node, and I think there is no ('clean') immediate way to get the WorkflowManager or the current NodeID in a NodeDialog or in any of the classes used for a node. Is that correct?

Are there any workarounds possible?


Turned out - getting the node to execute the workflow to its current position is possible - reapplying how the "Save Workflow" node was done.  See snippet below. 
That solves one part of the task to make the MetaNode Config dialog react in a step-by-step way (e.g. query a DB for possible values, make the user select one, query based on that for another column, make the user select again one... )

The next challenge I guess is to make the UI work that way...
Knime team - if you read that:  Could you point me to how potentially to modify the MetaNode Quickform execution to allow the same step-by-step navigation as e.g. the Web Interface allows?




for (NodeContainer nc : WorkflowManager.ROOT.getNodeContainers()) {
		            if (nc instanceof WorkflowManager) {
		                WorkflowManager wfm = (WorkflowManager)nc;
		                Map<NodeID, StringInputQuickFormInNodeModel> nodeMap = wfm.findNodes(StringInputQuickFormInNodeModel.class, true);
		                for (Map.Entry<NodeID, StringInputQuickFormInNodeModel> entry : nodeMap.entrySet()) {
		                	if(entry.getValue() == m_model) { 
		                		System.out.print("Execute Up to node" + entry.getKey());


Hi Lorenz,

first of - interesting but dangerous idea...

Let me first start with a disclaimer: if you want metanode dialogs mess with the underlying workflow the way you are describing it above, then those dialog pages will never be displayable in the WebPortal - there the communication with the underlying workflow engine is done very differently. Also for the WebPortal we are pushing harder for SubNodes to be the mechanism of choice. That will - starting this July (in Labs first...) - allow you to also execute loops and you could then repeatedly run a part of workflow, controlled by user input. SubNodes will also allow to model dependencies/communications between QF nodes in a later version. We can dive deeper into that if this is also something you are interested in?

If, however, you are really "only" interested in the client side GUI and how to create more complex dialogs using Quickform Nodes then you are still walking down a dangerous path. But then messing with the workflow engine is possible along the lines you describe. It is a bit messy because you end up controlling execution of a workflow from a thread that's dedicated to a dialog, though. You already figured out how to do that. The next problem is that if you execute (quickform) nodes under the hood of the dialog (which remains open), the dialog will not be informed about the changes in the underlying nodes settings - since KNIME assumes that the nodes' states don't change while the dialog is open, the dialogs don't register as, say, StateChangeListeners...

So the main problem really is that a dialog on a Meta- oder SubNode really shouldn't mess with the state of the nodes it is configuring by e.g. executing them (and if you look at the "configure" routines in the workflow manager you see that the WFM triggers all state changes, not the dialog!). That implies that you would need to keep that logic inside the dialog. It almost sounds as if we should expose some of the upcoming JavaScript scripting node framework not only to define customized views but also for customized dialogs...

Let me chat with Bernd when he comes back from the SF Dev Training today - I am sure he has some more comments!