Hi @stellarpower ,
I agree with your sentiments. There are many things that KNIME makes so simple and so many simple things it makes difficult.
PATH VARIABLES
In particular Path variables, for the reasons you point out, do feel "half baked’. It should not be necessary to do the continual path to string /manipulate / string to path conversion just to adjust a path slightly. I notice this keenly when using the various community nodes that assist with formatting a spreadsheet.
Chances are, if I write a spreadsheet and then want a formatted version of it, the new one is going to have a slightly modified name, (different subfolder or maybe just a name prefix or suffix change) and further, if the workflow is to be reusable the file path will be in a variable. KNIME paths and lack of direct Path manipulation nodes make this trivial job into a minor sub-project! This is why I end up writing so many components because I don’t like having to repeat myself in every new workflow.
There are two schools of thought on whether KNIME should provide additional nodes when a job can already be performed from existing ones. I am firmly in the camp that it should, where the task is a common one and is effectively boilerplate placement of (noise) nodes, or where the task itself is trivial but building it in KNIME requires the mind of an expert or a programmer to perform. The whole point is that difficult tasks should become less difficult (ideally easyl. It shouldn’t also be making easy tasks difficult.
By the way, in the case of path transformations you may be interested in the following component:
and it’s sister, which has been adapted for a workaround to a KNIME bug (which is increasingly frustrating my use of components) so that it can work inside conditional branches:
I wrote the above for exactly that scenario of minor modifications to paths without the mass of nodes. It would be great if KNIME had a dedicated component for this.
ROWID
The particulate use case you’ve cited is not one I’ve particularly had an issue with. I tend to use the RowId node to copy out the existing rowid for some future purpose or to update the existing rowids with a new sequential list. Maybe you use rowid more extensively than I do. But I take your point that often there are things requiring multiple additional steps for one node where in a different node equivalent behaviour can be achieved by a simple configuration setting.
SCRIPTS AS PARAMETERS
On to your (main) point about being able to write scripts or expressions as parameters, yes I also think that would be a great idea. I’m not sure whether it would be Java as you have out in the title, but certainly I think a common expression language across all node parameters would improve what is already a great tool astronomically. There are many occasions where I just want to pass “variable+1” or similar and inclusion of a new node for something trivial like that is always a pain to me.
There is a section here on the forum entitled Feedback & Ideas so that such posts don’t just disappear into the many “questions/solutions” and others can also give their support or feedback. I’ve moved this post there