Many of these comments reference decisions made in #70. Depending on feedback, some of this information is subject-to-change.
Back-end
The back-end provides two key endpoints that are helpful for adding custom Nodes on the front-end.
1) workflow/upload: Accepts a file upload via FormData. The existing front-end API wrapper for uploadDataFile can be used, just without the nodeId attribute added in NodeConfig.
2) workflow/nodes: Returns a list of available Nodes to the workflow. This returns the same response the /nodes/ endpoint used to, except now there is an additional 'Custom Nodes' category. If all packages are installed, this should proceed as normal. If not, the node information will be structured as such:
Custom Nodes work like any of the other Pyworkflow Nodes, so there is no additional work needed to add a Node to the Workspace, update Node info, execution, etc. The two new pieces needed for the front-end correspond to the two pieces mentioned above in the back-end.
1) Adding a new Node. This can probably use the same/similar code as the Node's FileUpload element does, just triggered from a different area in the workspace. One idea might look like this wireframe
where a + or Add custom node button is added at the bottom of the Node listing. This would pop-up the file picker, and trigger the workflow/upload endpoint. On success, a call to workflow/nodes would be made to refresh the list to include the newly-added custom Node.
2) Handling missing packages for custom Nodes. If the custom Node does not required any new packages to be installed, it should be ready to drag-and-drop like other Nodes. If there is a missing package though, it cannot be dragged and the name will either be the filename (instead of the class name attribute — my_custom_node vs. My Custom Node) or not appear at all.
A few solutions/ideas:
Group "bad" Nodes into a separate category/section in the sidebar. These could be prevented from dragged onto the workspace. A general error message is displayed for the entire category telling the user changes must be made.
A red ! symbol could appear that, when clicked, display a pop up with the missing package names and a message to the user on how to install them/restart the server.
Pie-in-the-sky scenario: a button is presented to the user to install the packages in-place without the user needing to leave the page (difficulty: max).
Some combination of the first two bullets is probably most feasible and reasonable.
Many of these comments reference decisions made in #70. Depending on feedback, some of this information is subject-to-change.
Back-end
The back-end provides two key endpoints that are helpful for adding custom Nodes on the front-end. 1)
workflow/upload
: Accepts a file upload viaFormData
. The existing front-end API wrapper foruploadDataFile
can be used, just without thenodeId
attribute added inNodeConfig
. 2)workflow/nodes
: Returns a list of available Nodes to the workflow. This returns the same response the/nodes/
endpoint used to, except now there is an additional 'Custom Nodes' category. If all packages are installed, this should proceed as normal. If not, the node information will be structured as such:Front-end
Custom Nodes work like any of the other Pyworkflow Nodes, so there is no additional work needed to add a Node to the Workspace, update Node info, execution, etc. The two new pieces needed for the front-end correspond to the two pieces mentioned above in the back-end. 1) Adding a new Node. This can probably use the same/similar code as the Node's
FileUpload
element does, just triggered from a different area in the workspace. One idea might look like this wireframewhere a
+
orAdd custom node
button is added at the bottom of the Node listing. This would pop-up the file picker, and trigger theworkflow/upload
endpoint. On success, a call toworkflow/nodes
would be made to refresh the list to include the newly-added custom Node.2) Handling missing packages for custom Nodes. If the custom Node does not required any new packages to be installed, it should be ready to drag-and-drop like other Nodes. If there is a missing package though, it cannot be dragged and the name will either be the filename (instead of the class name attribute — my_custom_node vs. My Custom Node) or not appear at all.
A few solutions/ideas:
!
symbol could appear that, when clicked, display a pop up with the missing package names and a message to the user on how to install them/restart the server.Some combination of the first two bullets is probably most feasible and reasonable.