Roadmap for Path Support in Expression node

[fe145f9fb2a1f6b]

given the following post received no feedback, here again the question:

when can we expect Path type to be supported in the “new” Expression node? the nightly flagged as 5.11 does not include support yet.

Column Expression node has been set to legacy what feels like 2 years already.
Java Snippet is obviously the “current” solution, but not having a simple, build-in node or function in the default scope (installation) to e.g. separate filenames from paths without string wrangling, traverse up structures without having to string wrangle / or \ or append filenames (strings) to folder paths (path) seems just unreasonable for a automation tool.

[MartinDDDD]

Admittedly I am still using Column Expressions (legacy) for all path related topics - have to admit that there is always a bit of a feeling of being disappointed when I built a bunch of expressions in the new Expressions node and “just” have to take care of some “path”-topic, which I then have to do in another node… adding Path support surely would make Expression node a full-on swiss army knife.

[carstenhaubold]

Thank you for the feedback! We hear you, and we have been collecting your input on the Expression node for a while. We will work on implementing those improvements in Q2, and path support is a good one on the list next to e.g. array support and easier rule syntax.

[fe145f9fb2a1f6b]

the sad part is that this is the same feedback as received a year ago.

[fe145f9fb2a1f6b]

to add to this: Java Edit Variable does not support Path Variables either.

[Syndra_Casper]

I totally feel your pain on this. Relying on string wrangling for paths feels like a step backward when we’re used to the dedicated functions in the legacy node. For now, I’ve been sticking to the legacy Column Expressions node for path-heavy tasks, but it’s definitely not ideal. It would be great to hear from the dev team if Path support is high on the priority list for the next release, especially now that Date/Time support has finally landed!

[fe145f9fb2a1f6b]

I am ok with using the legacy Column Expression node, because it has so many more features (undocumented) that the Expression doesnt have / will likely never have:

you can create temporary variables to make complex steps more readable

or take advantage of standard methods of the respective datatypes, which Knime didnt document (afaik)

.

But, the Column Expression Nodes got flagged legacy, when the new Expression Node didnt even handle integers properly, let alone DateTime etc.

[MartinDDDD]

@fe145f9fb2a1f6b

you can create temporary variables to make complex steps more readable

Please vote for the variable feature here

Feature Request: Enable definition of Expression-internal variables in Expression Nodes / Filter out helper columns

Hi all, I’ve become a fan of the new Expression nodes and the KNIME Expression Language. That said two features that I miss and I think could add a lot of value in terms of making complex Expressions more readible are: Ability to mark “helper-columns” for exclusion from the output table: e.g. I create interim columns that are solely required for a final calculation in a downstream column - the helper columns that enable the “final” Expression are not needed and I typically filter them out u…

(Fully agree - that’s why I like the legacy version a lot)