I would like to see Components moved to, or duplicated to the Node Repository (or given their own boxed off / separate Component Repository) and have both share the same search bar.
Components basically function as specialty Nodes, yet they are treated more like workflows in the current layout. They lack separation from workflows (which are not used similarly), and the quick access tools given to nodes such as hot key accessible search bar and hot key placement functionality.
I find myself wasting time searching different names in the Node Repository for what it turns out was a “component” and looking for “specialty nodes” buried in with workflows files, when they can serve identical functions.
When I want to drop a component or node, I should be able to search for them in the same place. They could easily be marked as components or separated to avoid confusion with “official” nodes and still improve the UI.
A component is not a node, but rather a collection of nodes. It’s built on a or multiple nodes and is dependent on these nodes.
A Knime node is different.
I do build by components as re-useable and they do reside in a specific folder where they are classified in categories as sub-folders, and then further sub-categories if needed with another level of sub-folders. I can drag any of these components to any of my workflows. So, I’m already operating as if I have a “Component Repository”. However, of course I cannot search a Component like we can search a node, so this option I would like.
A component is a certainly “a collection of nodes”, but it is also packaged to function like a single node. It may be constructed like a workflow, but it is surely used much more like a node.
Components are dropped into workflows to perform a function just like nodes. For some reason, they are buried in with the workflow files. Why not give them their own repository and have the node repository search bar filter both? It makes much more sense to search for some function and then see all of the pre-built tools available to you.
Yes, we can create a file structure to try and keep components separate from workflows and as organized as possible, but that doesn’t make for good UI.
I understand @iCFO . But the point I was trying to make was more about the title of “Move Components to Node Repository”, in the fact that they are not nodes.
But I would like to be able to search a Component like we can search a Node, and I would go with a Component Repository instead of moving the components to the Node Repository.
There may be some debates or questions though. For example, Node names are unique as far as I can see, while Component names are not. They are user defined, uncategorized, basically “undisciplined” . Not sure how that Repo would look like.
And how would it work with linked components? For example, if you use a linked component from the hub, should it be part of your local Repo?
Don’t get me wrong, I’m not trying to “combat” the idea or saying it is wrong, I’m asking these questions as I am sure they would come to mind if the idea is implemented. Just playing the Devil’s advocate here
Good point mentioning the devil, it’s a good way to discover flaws.
I don’t use shared components myself (I have only one), but I view nodes as equivalent to functions in programming languages. Nodes in the repository are base functions (printf etc.), Components are custom functions defined within the program (printMyStuff) and shared Components are functions imported from custom libraries. Metanodes are just collapsed code. Extensions are “official” libraries. Kinda works out (shared Metanodes shouldn’t exist).
With that perspective, shared Components should also go into the node repository, possibly under its own branch “custom” with the ability to further divide it into themes. That way, we could search and access them like any other node, which is probably how it is supposed to be.
btw, @bruno29a, there’re already 3 Metanodes in the node repository, you can find them under Other Data Types → Time Series → Meta Nodes
There’s an opposing design principle though: Creating and maintaining shared Components is supposed to be easy, and the node repository is read-only. I guess that’s the reason they have been placed in the KNIME explorer.
To get the best of both worlds, we could store the blueprint/source code of the Components in the explorer for creating and maintaining them, und access them for usage in the node repository like any other node. Components from the Hub would then only show up in the repository. This would also require the most effort from the devs.
I also agree to have an editable category for components in node repository.
In general, I suggest to have something like extension update sites for verified (KNIME) and community components so one can add them to their repository just like other nodes.
As far as I know, only components developed by KNIME team members can be verified but if KNIME really wants to outsource the functionality expansion through shared components, I think they should give credit to components and their developers among the community. I know there are some efforts to highlight components built by community and those moves are really charming but I think the concept of components is great enough to build a platform for it. It shouldn’t be that complicated to provide a system through which one can provide a component and then it gets tested and verified. Even this process can be outsourced to the community. E.g. a component gets verified if n number of users admit they have tested the component successfully.
Simple User Interface tricks can easily handle most of the challenges I have read here. (Linked components could be identified by a chain icon, verified components could be identified with a green checkmark icon. Knime Hub components could be identified with the existing icon. etc.) It shouldn’t be restricted to “verified components” though… We need all of these same tools to be able to manage our local / privately shared components as well.
Showing components in the node repository under a “components folder” is certainly the quicker / easier change to the platform. There are several ways that this could be done. There could be a set “Components” folder in the workflow area which basically duplicates your file structure and components within the node repository (making them searchable and accessible by hotkey). Or a right click option for “show in Node Repository”. Duplication can lead to clutter though, so I prefer the below approach.
The better approach from a UI standpoint would be to tackle the bigger project of a Component Repository (or divided component section within the Node Repository). This would essentially function like a hybrid of the Workflow area and the Node Repository, giving searchable drag and drop access while retaining the right click options from the workflow area and folder organization capabilities. I would also have KNIME Hub components appear in the Components Repository and KNIME Hub workflows appear in the workflow area.
. Not sure how that Repo would look like.
