Node parameter types, configuration form, and persistence

PyWorkflowApp / visual-programming

A Python Visual Programming Workspace for Data Science

MIT License

33 stars 12 forks source link

Node parameter types, configuration form, and persistence #34

Closed reddigari closed 4 years ago

reddigari commented 4 years ago

Fixes bug where session graph was not getting updated by /new and /open endpoints (because they are exempt from the middleware)
Defines OPTION_TYPES attr on ReadCsvNode, and sends to front-end in node list
Renders node configuration form based on these fields and types
Adjusts the JS CustomNodeModel to distinguish between node info (e.g. name, color) and config options (filename, delimiter)
Integrates node configuration with update node endpoint

~Although options set on the front-end via the configuration form are maintained in the JS state, I haven't hooked it up to the endpoint that updates nodes on the server. If I get it done before this PR is merged, I think it fits in here well.~

reddigari commented 4 years ago

While working on integrating the update node endpoint, I realized that I fucked things up by changing the signature of node_factory(). It's also used in pyworkflow.Workflow.get_node(). I'll try to fix this tomorrow. Sorry!

reddigari commented 4 years ago

Reverted the node factory behavior, and integrated the update node endpoint. Now configuring a node on the front-end is reflected on the server!

To test:

Create a Read CSV node (the only one with parameter types set up)
Click the gear, fidget with the options, click save
(Keep an eye on the terminal to see the server responses --- the update endpoint sends the computational representation of the updated node)
Save to JSON, clear the workspace, and load it back --- your configuration should have persisted (both on the front and back ends)

reddigari commented 4 years ago

@reelmatt Exactly, just for rendering the form. On the front-end they interact very slightly with the actual options to set the default values in the form, so the keys must match the DEFAULT_OPTIONS keys. The nested dicts feel super clunky so I'm open to some other representation if anyone's got one.

Just an explanatory note for anyone exploring the front-end code: options is already used by the react-diagrams base classes to indicate properties of the visual node (color, position, etc.). So I designated config as the attribute to store the back-end options (parameters for node execution). So when you see node.options.whatever, that's usually a static property of the node; node.config.whatever is accessing a configurable parameter that will eventually passed into pandas. Again, maybe worth refactoring if someone has something cleaner.