From what I see, the action is pretty much the same for the 3 sample cases:
1- Row Filter
2- Append columns from another table
Obviously with 3 cases, it’s OK to proceed this way. For 15 cases, it looks like it could be configured dynamically.
Just an idea off of my head, you could define the row filter rules in a table for each of the 15 cases. For the appended columns, it’s a bit more tricky, depending on how many rows you have, but still doable. You would still need to create all of these columns somewhere - either in a Table Creator, or read from a file. The trick would be the naming convention where the selection of the columns to append would depend on their names.
Again a very interesting and challenging question !
Sorry I’m replying from my smartphone and hence away from a computer so I cannot provide a workflow example.
Nevertheless the first generic idea that comes to my mind is to implement everyone of your Case-Switch options as a subworkflow and then call the right subworkflow based on its name in a variable. This would allow to easily implement a Generic-Dynamic-Case-Switch component of as-many-as-needed cases.
The number of rows is always limited, it’s usually just one row with a varying number of columns and headings. As the row filter is only for this example, usually the whole dice sim thing is a little bit more complex, but I didn’t want to blow up the example.
Right @kowisoft, this is how I would do it because as far as I know this is the only “functional” way of calling a piece of code in KNIME. By “functional” call I mean “passing a function as an argument when using a node” and this is what you need to create a “generic” Case-Switch implementation with a variable number of case-switches and their associated “actions”.
Every possible “action” would be implemented as a call by variable to a local workflow where the variable wiuld indicate its name among different possibilities that you would need to case-switch.
@kowisoft Each villain seems to have a completely distinct path, so I would take a rather different approach. I would start with a table with all the VillainNames, the VillainGoals and all the possible questions, like this one
I somehow got a result, but I really don’t understand how KNIME deals with JSON (I’m not a JSON expert at all). I recognize the table structure and how it is displayed in a JSON-way, but I simply do not understand how I could apply this to my example workflow.
The columns are always different and I always get back all results, which is not what I want.
Are you essentially trying to accomplish conditionally splitting rows into 15 different outputs so that you can process them all differently? Like a conditional multi-router?
If so, then I have built something like this in Alteryx in the past. Never tried to see how many outputs KNIME will allow on a component though…
It’s either the other way around. I have a table with 15 rows. Then I apply a dice simulator and based on the result of throwing that die, 1 row will remain. But it can be any of the 15 from the original table.
And based on the remaining row, you will have to execute some sub worklfows.
I think I have it somehow working right now and might publish my results here soon.
@kowisoft I thought my workflow could work because it outputs the same results as your example. I’ve worked on some ideas on the development of plots based on alternative choices. The following workflow is an example of how it could work
if we select action “alt2.1” this is the component’s output
Perhaps this workflow may be of some interest to those dealing with “potential literature”, following the example of the OULIPO. It would be interesting to explore (more seriously) the possible applications of Knime in this field.
Attention: If you want to download it, make sure to also download the folder subs including the 2 workflows sub1 and sub2
Looking at my final result, I must admit that my example was not the best one, because it leaves the impression, that the villain (in this stupid example) is the driver. But looking at the solution - the Villain’s Goal - is in the end what drives which sub-workflow is executed.
If you consider this, in the examples above you could e. g. choose either “The Joker” or “Doc Ock” and get different results, driven by the goal.
That’s also what my main goal in my adventure creator workflow is. The idea there is that you have a master table with 15 different villainous goals (such as “Economic Power” or “Destroy Good-Aligned Group” and then - based on this “category decision” from the master table, you will derive the sub workflows and their “additional” columns.
Sometimes it’s just 1 additional column, sometimes more…
I know that this is - once again - kind of a nerdy use case, but I am pretty one could translate this into business purposes as well - e. g. think about extracting assets including their asset classifications from an ERP system and then - based on the asset class - do different calculations.
I really hope these nerdy ideas help more people than just me
Sorry I’m replying late to your posts and questions about the JSON implementation since it is only now I have access to a computer with KNIME.
The good news is that you got the idea and managed to implement it eventually !
I had a look at your solution and it could be implemented in a simpler way just by using the -Call Local Workflow (Table Based)- and the -Container Input (Table)- nodes. I do not think one needs the JSON versions in your case although it is a very good example illustrating how to use them too.
Using the -Call Local Workflow (Table Based)- and the -Container Input (Table)- nodes, you would not need to go through JSON settings and conversions as in the solution showed here below :
This illustrates how a generic CASE-SWITCH scheme controlled by a variable could be implemented with as many switch options as sub-workflows needed for that.
Again, @kowisoft you posted here a very nice challenge !
It seems like this still performs the same function as a row filter in combination with a conditional multi-router. I personally prefer to keep alternate processing branches within the same workflow for easy review. However, I can see how this approach would be useful for a large number of branches, extensive alternate branch processing, or to allow for easier updating via shared sub-workflows if this workflow were scaled out to multi-users and projects.
If this “rolling dice” thing is the same as randomizing I would first think of generate random numbers, assign them in the workflow and then pick the “lucky number 7”
(But I am not too deep into this topic so I am probably missing something. Anyway thanks for sharing your solutions. As always very interesting)
br
)
