GitHub user yangzhang75 added a comment to the discussion: Proposal: Workflow
Templates — save a workflow as a reusable, parameterized template
Following the UX we've converged on above, here's the concrete design to
implement it.
## Agreed decisions
1. **Cardinality — 1‑to‑n.** A template can produce many workflows — sharing it
with N users, or running it on different datasets, naturally yields multiple
separate instances.
2. **A generated workflow is just a normal workflow** — user‑owned, fully
editable, like any other; it records which template it came from (for the tag).
The only difference is *how* it was created. (How tightly it stays tied to that
template afterward is open — see Open question 4.)
3. **A "from template" tag** distinguishes generated workflows.
4. **Always visible regardless of the feature toggle** — once generated, it is
a workflow (like one created by uploading a JSON), so it persists whether the
feature is on or off.
5. **The feature toggle is set before deployment, not at runtime.**
6. **Configurable properties** = a per‑operator `configurableProperties`
whitelist stored in the workflow content; the server applies submitted values
only for keys in that whitelist (e.g. a Filter's `price < 20` becomes `price <
X`; the user sets `X`, and the server refuses to write any non‑whitelisted
property).
Motivation: give users who find the canvas too complex (e.g. biologists) a
simple, form‑based way to create a workflow.
## Data model
**`template`** holds the template (a snapshot of the workflow content, incl.
each operator's `configurableProperties` whitelist). **`workflow_of_template`**
maps each generated workflow back to its origin template — one template → many
workflows (`tid` not unique), used only for the "from template" tag /
provenance.
```mermaid
erDiagram
template ||--o{ workflow_of_template : "1 template -> N workflows"
workflow ||--o| workflow_of_template : "origin of each generated workflow"
template {
serial tid PK
varchar name
varchar description
text content "graph + per-operator configurableProperties whitelist"
timestamp creation_time
timestamp last_modified_time
}
workflow_of_template {
int wid PK "FK -> workflow, ON DELETE CASCADE"
int tid FK "-> template, nullable"
timestamp created_at
}
workflow {
int wid PK
varchar name
text content
}
```
Ownership/sharing reuse `template_of_user(uid, tid)` and
`template_user_access(uid, tid, privilege)`, same as workflows.
## User flow
- **Authoring:** from any workflow, the author clicks **Make Template** and
ticks which operator properties stay editable (stored per operator as the
`configurableProperties` whitelist). Saved and shared like a workflow.
- **Using:** anyone with access opens the template, fills the configurable form
(with an optional read‑only preview — see Open question 1), and hits **Submit**
→ a new, fully‑editable workflow they own, marked with a "from template" tag.
Each Submit creates a new workflow.
## Services
Single `/api` gateway → distinct services: **amber** (`/template/*`,
`/templated-workflow/build` + `/{wid}/update`, `/workflow/*`, execution
WebSocket); **workflow-compiling-service** (`/compile`, preview schema
propagation + validation); **file-service** (`/dataset`, file parameters);
**computing-unit-managing-service** (`/computing-unit/*`, run unit);
**PostgreSQL** via DAO/jOOQ.
## Open questions
1. **Inline runnable preview on the build page.** Keep the
read‑only‑but‑runnable preview under the form — so after changing a parameter
and clicking Submit, the user sees the resulting workflow right below and can
run it immediately (without leaving the page)? Or drop it and just create the
workflow?
2. **Template deletion.** When a template is deleted, should its generated
workflows keep showing "from template" (keep the id), or lose the tag (`tid`
set null)?
3. **A "generated from this template" list on the template page.** Should the
template page list the workflows generated from it (with, e.g., generation time
and version history), so users can find them?
4. **Coupling after generation.** We agreed each Submit creates a new workflow.
What tie does a generated workflow keep to its template? Options:
- **live link** — the user can later re‑apply the template's form to update
that same workflow;
- **fully detached** — keep only the id for the tag; manual editing only
from then on;
- **template keeps a runnable snapshot** — the template retains the first
generated version, so the user can run it directly on the template page.
Hard case for the "live link" option: if the user deletes the operators the
template marked configurable, the template can no longer update that workflow
(nothing left to write).
GitHub link:
https://github.com/apache/texera/discussions/6070#discussioncomment-17588191
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
