I’m trying to make a number of reusable components using R scripts. They produce text, a table or a plot which all are nicely propagated to the highest level. Super!
When a lower level component requires a configuration node this unfortunately isn’t propagated to a higher level (see older issue on this forum).
The work-around suggested to copy those configuration nodes to the higher level components and pass the parameters via flow variables, makes those lower level components less reusable.
Is it possible to propagate configuration nodes to higher levels like this is done for output in the Interactive Output?
I wrote that earlier forum post. I changed my opinion since then.
Automatic propagation of Component configuration to a higher level would mean that Components would behave differently from normal Knime nodes. The configuration of these normal nodes is also not propagated to higher levels. I think Components should behave like normal Knime nodes as much as possible.
Just like it would be undesirable in a regular programming language if the function parameters of a nested function would be implicitly added to the parameter list of the encapsulating function, it would be undesirable here.
It is much better to make it explicit by copy-pasting the configuration nodes from a lower level to a higher level, and then pass the values from the higher to the lower level through the Flow Variable tab of the Component dialog window (as suggested by @lisovyi in that earlier forum post) .
In summary: after some contemplation, I vote for keeping the current system. I think it is the best solution for workflow abstraction/encapsulation.
With complex enough components you will need 10s of such Configuration nodes on the top level and you are not allowed to group them in any way. Meaning whatever you do, it will be and look like a complete mess.
I can agree that there should be a setting if the configuration is bubbled up or not and by default it should be off (also for backwards-compatibility reasons).
[quote=“Aswin, post:3, topic:23865”]
Just like it would be undesirable in a regular programming language if the function parameters of a nested function would be implicitly added to the parameter list of the encapsulating function, it would be undesirable here.[/quote]
On the other hand say in python with multiple inheritance and “mixins” that behavior is actual what you want. Your class inherits all the fields and methods of the parent classes avoiding you to have to repeat things.
Having to have the configurations duplicated + some flow variable magic isn’t DRY or easily reusable as components should be.