Manipulation of multiple selection configuration node

[jede04]

Hello,

I am looking for a better way to manipulate the data received from a multiple selection configuration node.

For example:
I have a node setup like below. You have multiple options you can select in the list.

After that I have a variable Expressions node in which I want to set what I want to do with each option that is selected.

Now the issue is that for every option I add, the amount of possibilities increases exponentially and it becomes easy to miss one.

I have been breaking my head over ways to make this easier, but I haven’t found a way yet. Is there maybe someone else who has come up with solutions for this.

Kind regards,
Jeroen

[aliasghar_marvi]

Hi @jede04,

Thank you so much for posting your query on the forum. Well certainly looks like there is some serious logic building. However, what would really help is, if you can mention what exactly your use case is. Maybe you don’t need to specify all selections in each if/elseif block. I believe members of the community will be more able to help if they could know what do you wish the outcome of your workflow should be.

Thanks

Best,
Ali

[jede04]

Thank you for your reply.

I am trying to build a query based on the parameters selected in the configuration. These parameters would be used in the WHERE clause of an SQL query.

We have 2 categories, in this case Food and Furniture, as subcategories of Food we have Vegetable and Fruit, and subcategories for Furniture are Chair, Sofa and Table. These subcategories will never be the same in multiple categories so we don’t have to worry about making sure we are in the correct category before looking for subcategory.

In the variable expressions I have the following. Say we want to select all records that are furniture or vegetables, then we need to use both category and subcategory fields which makes it impossible to use a simple IN function.

The moment I add another option to the list I need to update every possibility which is very inconvenient.

I hope it is more clear like this as I can’t give the exact details due to company data.

Kind regards,
Jeroen

[aliasghar_marvi]

Hi @jede04, so now it makes sense. So essentially what you are looking for is called, “Cascaded” selections. So you select one field and other corresponding options are selected. You just need to separate out the parent categories first. I do not have an immediate example with me but I will like to point you to certain resources I found on KNIME Hub:

• Cascading Dialogs – KNIME Community Hub

• Cascading Dialogs to Dashboard – KNIME Community Hub

I hope it helps, maybe instead of using configurations you can choose to use widgets and it will tremendously help to narrow down your if/else blocks.

Thanks

Best,
Ali

[takbb]

Hi @jede04 , welcome to the KNIME community!

It feels to me that the issue here isn’t so much one of manipulation of the multi selection config, but more how to specify what the chosen options mean, and how to identify which options are “category” and which are “sub-category”.

(I see @aliasghar_marvi has replied while I’ve been thinking about this, and the observation that ideally this would be performed with multiple cascading widgets is reasonable, but I’ll continue )

If this were being built as a component, a pair of multi-selection list boxes, one with each might also make sense in this regard. But again, I’ll continue with it being the one selection box.

As you have noted, the list will just grow exponentially as more options are added, so irrespective of the mechanics of how the selection is being made, something needs to change in how to build the query…

Is it reasonable to say that if you chose categories X1, X2,… Xn and sub-categories Y1, Y2,… Yn , the query to be built should be:

AND ( Category IN (X1, X2,… Xn) or SubCategory in (Y1, Y2,… Yn) )

If so, then what you could do is divide out the selections that are for category and those which are for subcategory.

The attached workflow is built as a component for testing (which you can open to see the logic)

Within the component, a table of selectable options is created which defines whether an item is a category or subcategory

The first column of this table is turned into a variable that becomes the selectable options in the config node.

Once selected, the selection options string is turned back into a table of values and joined to the original options table to determine which are categories and which are subcategories.

These are then split out and processed individually to create the respective conditions for each, and then merged into a single variable that is returned.

Build Query from selected options.knwf (44.3 KB)

It includes “1=0” as a placeholder for no value being selected for one of the types, this is more convenient than additional logic to change the general construction of the conditional query according to whether any category or subcategory has been chosen, but can be safely included as it always returns false, so doesn’t affect the result.

[gonhaddock]

Hello @jede04 and welcome to the KNIME community

Sorry because I didn’t spot this topic before…

@jede04

After that I have a variable Expressions node in which I want to set what I want to do with each option that is selected.

Now the issue is that for every option I add, the amount of possibilities increases exponentially and it becomes easy to miss one.

Besides @takbb 's approach. My feeling is that ‘Variable Expression’ node is not the right approach for your use case. There is a more simple approach tat may fit in your workflow:

You can try to feed the selected variables into the Multiple Selection Widget as a String List variable (highlighted in yellow)

You can find an example on how to implement it in this JKI Challenge workflow:

Just KNIME It S02 _ CH07 _ Mapping Successful Football Passes – gonhaddock

I hope this helps.
Happy KNIM(E)ing

[jede04]

Thank you for your reply.

I was looking into this, but I don’t see a way this can help me as both categories can be selected at the same time.
Also we have these options preselected by developers and then users can run the query when they want and shouldnt change anything, so using Widgets would not work either.

This information is not in vain though as I am sure I will be able to use it somewhere else

Thank you

[gonhaddock]

Hello @jede04
Despite your latest post was not an answer to me, I just want to to clarify/upgrade my previous post.

In the football match provided example taking a wider window, you have a sequence of filters: in first instance a Value Selection (optional) that slices the data set. For your use case, the Multiple Selection Widget would be connected to the output of the effective Value Selection Filtering.

Then the Multiple Selection Widget will display only available options for the selected variable in 1st instance within Value Selection Widget / Filter. No hard coding would be necessary.

The necessary change for your use case would be that the port conector has to be sequential (as the green line) instead to be in parallel. Therefore, in the case of a unique component, the sequence of display and refresh buttons wouldn’t be very friendly but functional. You may need to disaggregate it into two components.

BR