The Table Editor is not actually responsive to the incoming domain. It seems to be instead auto calculating and ordering the domain internally for some reason. This leads to an inflexible jumbled up dropdown order. See the interactive view of the Table Editor node for an example.
Table Editor Domain Bug.knwf (18.2 KB)
Hi @iCFO -
Can you confirm that unchecking the “Use domain of incoming table” box fixes the problem? It did for me, although it’s not… the most intuitive fix 
That did it! That setting definitely seems backwards to me… I am not sure if I would have ever unchecked that box. 
Thanks a ton @ScottF! This quick solution really opens up some big possibilities on my end!
I spoke too soon @ScottF… When it is not checked, it only shows the domain values that fall within the number of displayed rows. I need the full list of dropdown options for the entire domain in order. Not just what falls within the displayed rows in the table editor. See attached workflow.
Table Editor Domain Bug.knwf (18.6 KB)
If you would like to see a basic data manipulation example of how this might be applicable then feel free to check out the interactive view on this Header Re-Map component. (This is all really a workaround for the fact that we can’t just pass our own custom dropdown values / order to the node)
Once a few small problems like this are ironed out, I believe that I will be able to re-build our entire user interactive system within just the KNIME / Server platform.
Hi @iCFO,
This is indeed a bug in our implementation. We have just pushed the fix and it should end up in the 4.7.1 bugfix.
Best regards,
Robin
Thank you @robin_gerling! This is one of those times that I wish I wasn’t limited to just 1 
button hit!
I don’t mean to piggyback, but I wanted to throw out 2 more possible improvements that would open up a ton of options…
A “single select only” option for the drop-down. This would remove any current selections in the column from subsequent drop-down list options.
Currently I work around this with a log file / loop / join structure, but I doubt that that would be a practical approach on Server.
It would also be nice if the drop-down action itself was responsive to the first single click. It the interaction feels a bit clunky when it requires multiple fast clicks to access the drop-down values.
There is so much potential for this node to be used in building client facing interactive controls on dashboards! 
Hey @iCFO,
with the “single select only” option you mean that once you change a value in one row of the column, that all of the other values in this column also change?
We are aware of the “clunky” interaction to open the dropdown, but it was sadly not possible to solve this differently with the technology in place. At some point we will migrate this node to the new visualisation framework and in this go we will improve this interaction.
Best,
Daniel
Hey @DanielBog,
It would be a nice benefit if “Single Select Only” also changed existing duplicate values in the column to missing values. However, the basic functionality that I am looking for is essentially a filter that removes values that currently exist in the interactive column from the dropdown options. This functionality is obviously not for “basic table editing” (as there would be no available values in a dropdown unless the domain options are based on values that extend beyond the table row limit). Instead this is to open up possibilities for building user friendly control settings for data manipulation in interactive dashboards. I see this node as the key to building entire web based applications within KNIME alone which would allow users to writeback complex user input manipulations to the underlying workflow.
Try out the above linked Public Hub workflow to see what I mean. Make a dropdown selection, hit refresh, then make another dropdown selection. You will find that the dropdown no longer contains previously selected values. This component is using logs and loops as workarounds to accomplish this. This example is designed to simplify a basic “backend” task, but I would like to build this approach into more complex (Server ready) client side dashboard controls.
If we could base the dropdown selection options off a different column’s domain, then it would simplify many of these workarounds as well.
Glad to hear that this node will be migrated into the new visualization framework. That gives me more confidence in my approach improving over time.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
