Dynamic Component Configuration (Single Selection)

[Meline_dng]

Hi all,

I would like to build a component with a dynamic single selection configuration.
I want the Possible Choices of my Single Selection Configuration to be based on a column contained in a table. This table is the output of a shared metanode nested within the Component (and used in other workflows). For a demonstration purpose, I replaced it with a table creator in the example I share below.
I write the values of that column in a variable which I later use in the Single Selection Configuration node’s configuration.

My issue is that, if I import the shared Component in my workflows, the list is empty at first.

I have to run it once to have the list populated.

Since the content of my table evolves, i would like to avoid hardcoding the list.

Is there a way to not need to run the component once without hardcoding ?
Dynamic_Component_Configuration.knwf (33.7 KB)

[takbb]

Hi @Meline_dng ,

This is just the way it is with components when you want them to have dynamic configuration like this. I
create similar components and I just get used to the action of executing my components before configuring them just to pre-populate the dialog items. Admittedly when I give components to other people I have to explain that they need to be “pre-executed” before they can be configured as initially they think there is something wrong with it!

It’s probably worth taking a step back…

A component isn’t quite the same as a standard node because it is actually just a collection of nodes on your workflow that have been cleverly encapsulated to look like a node, so taking your component as an example, it’s internals look like this:

When you consider what it looks like in the above screenshot before you have executed it you can see that the Table Creator has not yet executed, and nor has the Get Brand List metanode, and these are obviously required to feed the Single Selection Configuration node.

So this is why the component has to have been executed (or at least attempted to execute) before that dialog can be populated. Put another way, the Single Selection Configuration node cannot “know” what its settings will be when the nodes immediately upstream of it have yet to execute.

The question in my mind is does it matter that you have to pre-execute it before you can configure it?

Provided that execution of the component isn’t performing a “permanent” operation prior to populating the dialog components (eg. updating a database, or writing a file), the fact that it behaves very slightly differently to a standard node ought to be only a minor inconvenience that you should be able to get used to once you appreciate why it cannot behave any other way.

As an example I have grabbed a screenshot from a different forum thread where I discuss similar behaviour in some of my own components…

I understand that it initially doesn’t quite feel right, but hopefully this explanation will help.

Does it actually cause any problems other than the extra manual “pre-execute” step that you are required to perform before you configure it?

[bruno29a]

Hi @Meline_dng , I’ve not checked your workflow, and hopefully I understood what your issue is.

This is something I have been trying to resolve when I first started using Knime, and I thought it could only be done when you create a node until may be a year ago when I discovered the Column Selection Configuration node or Column Selection Widget, and I believe it’s what you are looking for.

You don’t have to pre-execute the node to populate the dropdown. You just need to plug a table to it, and it will automatically populate the dropdown with the columns of the table connected to it.

I used this for a question from the forum, but I don’t remember which one it was.

I’ve created a demo for you here:

Dropdown with list of columns – bruno29a

[takbb]

Hi @bruno29a , you are right that the Column Selection and many other dialog config nodes can work without pre-executing based on the data table that is upstream of the component.

The example I was citing, and which I think applies here, is where the configuration isn’t purely from the input stream but is dynamically adapted according to some logic within the node. I have tried (but probably failed) to come up with a trivial example, but here goes. This is very contrived, but hopefully demonstrates what I’m referring to.

I give you “The Amazing Incredible Bilingual Day Number Selector”

The purpose of this incredible component is to take a Day of the Week selected by the user and its one job is to translate that drop down value into a number between 1 and 7 which is applied as a day number to the data table.

The dialog language for the days can be set to be either French or English depending on the setting of an upstream flow variable.

If the language is set to FR:

If the language is set to EN:

Because there is a calculation within the component (other than just the standard flow of columns or variables from upstream), the dialog cannot necessarily display the required config options (set according to the flow variable) until it has executed at least once, and thus been able to derive the dynamic contents of the drop down list.

So yes, you are right that in the general case, the component doesn’t require any pre-running for it to function, but in the specific case of dynamically creating the values for the dropdowns or other dialog controls, based on some additional logic, pre-executing is necessary before it can be configured.

This is, as I said, a contrived (and hastily thrown together) example, but I have a few components now where this does happen in real-world but somewhat more complex situations, where the dialog controls have to adapt to conditions (variable values or specific table data values) generated upstream.

Here is the amazing component in all its glory!
Dynamic Dropdown in Component.knwf (27.0 KB)

[bruno29a]

Hey @takbb , I think @Meline_dng is asking that the dropdown is prepopulated by the columns contained in a table, which can be achieved with the node that I suggested, that is if the node is supposed to be reading directly from the table. So it would not matter what manipulations need to be done, they can all be done before reaching that point.

In the end, I think the biggest issue here in @Meline_dng 's design of the component is that the table itself resides within the component, so I’m not sure how the table can be run without running the component.

Components should not be designed/used that way and it does not sound like it’s stand-alone the way I’m seeing it - I’ve not downloaded @Meline_dng 's workflow, but I was able to see what was in it via your screenshot.

[takbb]

Hi @bruno29a , I have plenty of components that are designed/abused this way…

Hopefully @Meline_dng can either live with the way it works, if the problem is as I think it is, or rework it so it behaves better if it is the way you think it is, but whichever way it goes, I hope this serves as a good discussion on component design and pitfalls

Actually, I was just looking at a totally different forum thread from a few weeks back that I hadn’t spotted before which gave me an idea for a reasonably simple component example…

International Dialling Code Picker – takbb

I’ve just thrown this together. Hope you like the icon . This is a component which allows the user to select a country/territory from a dropdown, and it will create a data table of one row with that country name and International Telephone Code. So by its nature, it is a data source, with no requirements for anything upstream which allows it to provide a good example of a dynamic drop down without too much in the way of complication. The list of codes is contained inside the component as a CSV file which is used to populate the dropdown. The dropdown is therefore dynamic in nature, and the component cannot know in advance what the values in the dropdown will be.

For the most part (and if I have not reset the data when sharing the component), the dialog would be in the populated state and all is good, but if the component is “reset”, the dialog is unpopulated and the component must be executed in order that the dialog be refreshed again.

If the component is in this reset state, the config dialog looks like this:

Only on executing once, does it contain the required configuration:

btw, I have no idea if that component will be of use to anybody but anyway, yes this may be not quite what the components were designed for, though I see no real reason why not, but ultimately what I’m saying is that if this is how the component is written, then this is the behaviour that should be expected, because the architecture cannot realistically be expected to operate any other way.

[Meline_dng]

Hi @takbb , hi @bruno29a ,

Thank you both for your detailed answers!

If I switch to the Column Selection Configuration node, the “unwanted” behavior remains.

@takbb

The question in my mind is does it matter that you have to pre-execute it before you can configure it?

If possible, I would prefer to avoid to pre-execute the node. Hence why I posted on the forum in case there was a way to escape it. Learn from the community if there is an alternative.
I fully understand why it is behaving this way, and if there are no tricks, it does not matter.

Thank you again!

[iCFO]

I think it would require a platform wide change to pre-execute components up to the configuration nodes when the a component configuration dialog is opened.

[takbb]

Yes I think you are right @iCFO. I think the current way it works is sufficient. I have sometimes included in the component description that it needs to be executed if the dialog isn’t displaying properly, and just occasionally even include something to that effect in one of the field labels on the component itself, because otherwise a casual user thinks something is broken, but apart from that I don’t think it causes too many problems.

@Meline_dng , I’m glad to hear that you can work with the way the components work. Thanks for the feedback!

Incidentally, I had to modify my demo component, as I hadn’t realised that on sharing the component it does not take data files with it, (plus I had actually coded it incorrectly even if it did, lol !) so I’ve had to replace the CSV Reader with a Table Creator. I don’t really imagine anybody will be using the International Dialling Code Picker but I have corrected it so that at least it now works in case anybody wants to experiment with the “dynamic” component.

This specific issue is mentioned here:

Store data in shared components

Hi, any news on the highly awaited feature? By the way, the data actually gets uploaded, stored, and downloaded, too. The problem is just that it gets deleted when saving the workflow locally. This is even the case for locally created nodes/components with data e.g. if you are trying to use “knime://knime.node”. It forces you to save the workflow before being able to use the protocol for nodes. Then you save it, aaand it’s gone (your data folder). Cheers Julianus

This is now going slightly off-topic although a continuation of my earlier post, but anyway anybody wondering how I managed to get a CSV file to work inside the component will realise that actually I didn’t… and I’m all ears if something has changed and there is now a way of sharing data files inside a “shared” component. (Always something new to learn! )

[Daniel_Weikert]

@takbb
Thanks a lot for clarifying the example. Yesterday I though what’s the problem everything works fine ^^