GitHub user yangzhang75 created a discussion: Proposal: Parameterized Canvas —
a second view of the same workflow
## Summary
A workflow gets two views of the same instance. The regular canvas is for
building and
editing it. The parameterized canvas ("P canvas") is a simplified view for
people who just
want to run it with different property values.
The author ticks a "parameterize" checkbox on the operator properties worth
asking about.
Those become the inputs on the P canvas. Everything else stays hidden.
The two views share one workflow instance, so a change made on either is a
change to the
workflow, and both stay in sync.
## The problem this replaces
In the design proposed in #7368, filling in a macro's form generates a
workflow. That leaves
the cardinality between a macro and the workflows it produces undecided, and
neither option
holds up.
**One-to-one (1:1).** A macro maps to a single generated workflow, so filling
in the form
again has to overwrite the previous result. Two users cannot hold different
parameter values
against the same macro, and one user cannot keep two configurations side by
side.
**One-to-many (1:N).** Every fill produces another workflow. The workflow tab
accumulates
near-identical copies of one pipeline, the ownership and lifecycle of each copy
are
undefined, and a later fix to the macro does not propagate to any workflow
already generated.
There is also more than one place to run the same workflow. The macro page has
its own Run,
and so does the workflow it generates. Two different objects execute the same
thing, and it
is not clear which executions belong where.
The P canvas removes both questions rather than answering them. Nothing is
generated, so
there is no second entity for a workflow to be related to. Run does appear in
both views, but
it is the same run on the same workflow, so every execution belongs to that one
workflow.
## The design
```mermaid
flowchart LR
C["Regular canvas<br/>build and edit"] --> W["one workflow instance"]
P["P canvas<br/>run with parameters"] --> W
W --> E["execution"]
```
A workflow offers a P canvas once its author turns that on from the workflow
tab, which is
also where it is opened from.
<img width="3006" height="1504" alt="image"
src="https://github.com/user-attachments/assets/5a43ed50-f797-4c1c-bd01-f3462c19f266";
/>
### Edit mode
Edit mode is where the author decides what the user has to fill in. It is
available to
anyone with write access. The author sets the page up in edit mode, then turns
it off to see
exactly what everyone else will see. Both are the same page, so there is
nothing to preview
separately and nothing that can fall out of step.
In edit mode the workflow appears and the author can click a step to open its
property
panel. A "parameterize" checkbox sits next to each of that operator's
properties. Ticking
one turns that property into an input the user fills in; leaving it unticked
keeps the
property out of sight, at whatever value the author set. The author can then:
- rename an input by clicking its title, so that a property the schema calls
`fileName` can
be presented as "Input file"
- hide sub-fields that are not worth asking about, since one property is often
several boxes
- add a line of help text under an input, if it needs explaining
- add an instruction for the page, written in Markdown
- choose which operators' results are shown after a run
- reorder the inputs by dragging
The help text and the instruction are both optional. An input with a clear name
usually
needs neither.
<img width="3008" height="1514" alt="image"
src="https://github.com/user-attachments/assets/e5d51d11-4d85-4d6f-830c-ecb895a2980e";
/>
<img width="3010" height="1524" alt="image"
src="https://github.com/user-attachments/assets/eaa20772-9ee9-4695-903e-548965d59302";
/>
All of this is stored inside the workflow itself: one field in the workflow
JSON holding the
ticked properties and their names, and one flag on the workflow saying it
offers a P canvas.
Nothing is kept anywhere else, so the setup travels with the workflow and there
is no second
record that can fall out of sync. Clear those two and the workflow is an
ordinary workflow
again, which means the rest of the system never has to know this feature exists.
### What everyone else sees
The instruction, the parameter inputs, a Run button, and the results.
The workflow itself is optional and hidden by default. It sits behind a
collapsed strip that
anyone can expand if they want to see what actually runs, but nobody has to
look at a graph
to use the page.
<img width="3014" height="1530" alt="image"
src="https://github.com/user-attachments/assets/2ddbd37d-bf73-48f5-a1a4-177b00275fdc";
/>
<img width="3004" height="1530" alt="image"
src="https://github.com/user-attachments/assets/efd32e39-0bcf-4c05-bfc9-a12eccbb132d";
/>
<img width="3006" height="1520" alt="image"
src="https://github.com/user-attachments/assets/ea49d624-ffd7-4ba1-a4f8-acaee0943e74";
/>
### Cloning
Cloning or duplicating a workflow carries the parameterize checkboxes with it.
Someone handed
a parameterized workflow can clone it, open the P canvas straight away, and
fill in their own
values without ever seeing the graph.
### Staying in sync
The workflow is the ground truth. Filling in a box on the P canvas performs the
same property
edit the regular canvas performs, so a change on either view appears on both,
and Run starts
the same execution either way.
GitHub link: https://github.com/apache/texera/discussions/7807
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
