Easy modification of path format

[laval]

Hi everybody,

since paths are not string based anymore, I am struggeling with frequent changes of path variables or columns. I usually combine parts to large number of path variables as well as reading a path of a file and extracting parts from that and recreating new paths out of it. Unfortunately, for this purpose I have to convert the path always to string first, change that with the string manipulation node and reconvert back to path of the new informations.

Recently KNIME told me I can easily achive that with the new Expression node. I was very happy about that, but realised it seems to not accept the path format in a table or variable - it is simply not shown on the left side. Am I doing something wrong or is there another easy way without converting? If not I would like to suggest to extend the expression node if possible or to provide nodes able to work with the path format linke a path manipulation node.

THX
Lars

[takbb]

Hi @laval , I agree that modifying paths ought to be much more straightforward than it is, and that common need of my own caused me to write my “Edit Path Variable Filename” component

Edit Path Variable Filename – takbb

It has some shortcomings (probably more than I’ve discovered) but it can save me time when I want to adapt file names (such as creating a “destination” version of a “source” filename).

It would be nice to have simple no-code editing of paths directly within KNIME and I’ve added my vote, and totally agree that support for Paths in the new Expressions nodes is needed.

Within KNIME though, although not codeless, the existing Variable Expressions and Column Expressions nodes (part of the "KNIME Column Expressions (Labs) extension, if you haven’t already got it installed) do support Path variables and Columns.

e.g.

[laval]

Hi @takbb ,

thanks a lot for your comments. I checked the lab version the way explained by you and can confirm that this seem to support the path format. You can even filter the Functions for Path only. That also explained why KNIME said it should work now, I just missed the information ‘Labs’. Now I just need the K-AI inbuilt for easy use of the nodes.

All the best!
Lars

PS. I will try your component too^^

[laval]

Hi @takbb ,

I am just checking KNIME 5.4.0 for the Variable Expression node. I did not find a labs version there. But the one included shows “not supported”

The legacy version of this node works as the former labs node with path variable. Seems to me like a step backwards - can someone confirm and explain the findings?

THX
Lars

[takbb]

Hi @laval,

The original “labs” versions of Column Expressions and Variable Expressions should continue to be available with 5.4, but they have always been part of the “KNIME Column Expressions” extension, rather than the core nodes (now renamed to “KNIME Column Expressions (legacy)”) so you need to install that extension for them to show up in the node palette.

I personally feel that calling the new nodes “Expression” and “Variable Expression” (with the singular “expression” instead of plural “expressions”) was a poor choice of naming that was bound to cause confusion (as it already has on a number of occasions here on the forum). I would have gone with a totally different name! “Expression” is a good, it’s just it was already “taken” so maybe something like “Formulator”, “Manipulator”, or “Transformer”

Whilst these new nodes represent a shiny future, they are single-statement and certainly do not currently, (will they ever?) replace the multi-statement Column Expressions and Variable Expressions.

The new nodes are actually more analogous, and provide a similar use case to the String Manipulation, String Manipulation (Variable), Math Formula and Math Formula (Variable) nodes, but again are not a totally pluggable replacements (Math Formula doesn’t support creation of Long numeric data but does support Integer, Expression supports creation of Long Integer but not Integer), for example.

The older Column and Variable Expressions (plural) nodes may well now be considered “legacy” but you simply cannot perform the same multi-statement scripts with the new nodes and I therefore think it is wrong to consider that the new nodes in any way make these old nodes redundant, even if they have been renamed “legacy”.

In my view, a node should only be considered “deprecated” or “legacy” if its capabilities are available in a new “non-legacy” mechanism, and that is certainly not the case here.

My recommendation is therefore to try to use the new nodes where they can do the job you need them to do, because these are the future and so will be better supported, and are still evolving.

But the nodes are your servant, and you are not theirs, so where you still need the functionality of the old nodes, continue to use them until such time as the new nodes (or some other new nodes) can provide the functionality you need.