You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@texera.apache.org by "yangzhang75 (via GitHub)" <gi...@apache.org> on 2026/08/26 23:28:31 UTC
[I] Form View: a form-based view for running a parameterized workflow [texera]
yangzhang75 opened a new issue, #8011:
URL: https://github.com/apache/texera/issues/8011
### Feature Summary
Today a workflow can only be used through the operator canvas. That's the right tool for authors, but
too much for someone who just needs to change a couple of inputs, run, and read a result.
Form View is a second, form-based view of an existing workflow. An author marks selected
operator properties as "exposed"; a reader opens the same workflow as a simple form, fills in those
inputs, runs it on a computing unit, and sees the results the author chose to surface. It edits the
same workflow the canvas does — never a copy. It is offered only for workflows marked
isParameterized, and the whole feature is gated behind a form-view-enabled config flag (default off).
### Proposed Solution or Design
A new /user/workflow/:id/parameters page (WorkflowFormComponent) reusing the existing workflow graph model, the read-only workflow-editor + mini-map preview, and the property editor — the form is a lens over the same shared graph, not a fork.
- Authoring: in the property editor, tick which properties are exposed and give each an editable label, backed by a parameterization service that owns the operator↔field bindings.
- Reader: exposed bindings render as ngx-formly fields; edits write back to operator properties; an optional author instruction (markdown) shows above; run/stop reuses the canvas run-button state machine plus a computing-unit selector; chosen results render as cards.
- Persistence: an is_parameterized column on the workflow (migration 42) with endpoints to read/set it, carried through workflow listing/search.
- Feature flag: form-view-enabled (served via /api/config/gui as formViewEnabled), default off, gating every entry point (dashboard toggle, route, canvas menu switch).
Delivered as 16 stacked sub-issues, bottom-up:
- [ ] formview-pr1-flag — feat(config): add form-view-enabled feature flag, default off
- [ ] formview-pr2-backend — feat(workflow): persist is_parameterized and add Form View toggle endpoints
- [ ] formview-pr3-types — feat(workflow): shared types and collab-model support for Form View
- [ ] formview-pr4-parameterization — feat(workflow): parameterization service for Form View bindings
- [ ] formview-pr56-property-editor — feat(property-editor): choose which properties the Form View exposes
- [ ] formview-pr8-harness — test(workflow-form): add the shared Form View spec harness
- [ ] formview-pr8a-shell — feat(workflow-form): Form View page frame — load, title bar, save
- [ ] formview-pr8a2-preview — feat(workflow-form): embed the read-only workflow preview
- [ ] formview-pr8b-inputs — feat(workflow-form): render the exposed inputs and write values back
- [ ] formview-pr8b2-instruction — feat(workflow-form): show the author's instruction
- [ ] formview-pr8c-run — feat(workflow-form): run the workflow from the form
- [ ] formview-pr8d-results — feat(workflow-form): show the chosen results
- [ ] formview-pr8d2-inspect — feat(workflow-form): open a step to inspect its settings read-only
- [ ] formview-pr9-author — feat(workflow-form): authoring mode for building the Form View
- [ ] formview-pr10-computing-unit — feat(computing-unit): remember the selected unit per workflow
- [ ] formview-pr11-entrypoints — feat(workflow-form): add the Form View entry points and turn it on
Rollout: the flag stays off through the whole stack; the final PR (formview-pr11-entrypoints) flips it on and wires the entry points.
### Affected Area
Storage / Metadata, Workflow UI
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "mengw15 (via GitHub)" <gi...@apache.org>.
mengw15 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5458547497
Read through the series (and the `formview-mvp` branch) ahead of reviewing the PRs. Three design-level points, raised here once rather than piecemeal on the slices:
**1. agent-service will erase the form definition on save.** `agent-service` keeps its own copy of `WorkflowContent` (`agent-service/src/types/workflow.ts`) and rebuilds the content object from that allowlist before POSTing `/workflow/persist` (`workflow-state.ts`, `getWorkflowContent()`). Any agent edit to a parameterized workflow drops `parameterization`, while `is_parameterized` stays on — the form becomes an empty shell. The same copy already lacks `settings.executionMode`, so an agent save silently resets the execution mode today. The plan probably needs an agent-service slice (or fold it into formview-pr3).
**2. The read-only path needs an explicit decision.** For a user with READ access, the MVP form is fully editable: the input cards are standalone form groups not covered by the modification lock, so typed values go into the shared-editing doc (co-editors see them live), every autosave is then rejected by `/workflow/persist` with 403 and surfaces the "Could not save" toast on each debounce, and Run still works because execution is gated on computing-unit access rather than workflow access. This path is reachable from the normal UI: the dashboard entry-link rewrite and the form page's redirect both check `formViewEnabled && isParameterized` but not `readonly`, so a workflow shared read-only (or any public one, since `hasReadAccess` is true for those) opens straight into it. Worth deciding once at the design level — redirect read-only users to the canvas like the flag-off case, render the inputs read-only (view and run with the stored values), or scope the form to write-access user
s for the first release.
**3. Question, not blocking: why an `is_parameterized` column instead of deriving from content?** The single-workflow paths don't need it — `retrieveWorkflow` returns the content, and the form page already redirects based on the loaded workflow. The column seems load-bearing only for the dashboard listing affordances (icon, entry-link rewrite, list-page toggle), since listings don't select `content`. If that is the rationale it's a reasonable trade — worth recording it in formview-pr2 together with the cost it imposes on `/persist` (the extra fetch-before-update needed so a plain save doesn't reset the flag).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "yangzhang75 (via GitHub)" <gi...@apache.org>.
yangzhang75 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5486685596
Closing the gating-model thread: going with the always-available shape rather than a per-workflow capability gate.
- The Form View is available for every workflow. With no exposed inputs it is a one-click run page (Run + results); exposed bindings enrich it.
- The per-workflow bit is a default-entry preference, `default_view` (canvas | form, default canvas), not a gate. It only picks the landing view; both views stay reachable from each other, and nothing redirects away from the form.
- Backend landed in #8125: a `default_view` PG enum column plus a `set-default-view` endpoint, carried through listing/search and every copy path.
What this settles for the later slices:
- pr8a (page frame): the form page renders for any workflow while the feature flag is on, rather than redirecting when a workflow is not marked.
- pr11 (entry points): the canvas/form switch appears wherever the flag is on, and the dashboard control sets `default_view` rather than gating availability.
- an un-curated form defaults its results to the operators the workflow already marks for result viewing.
- read-only visitors see the inputs read-only and run with the stored values, consistent with the read-only canvas, no redirect.
The feature stays behind the form-view-enabled config flag (default off) through the whole stack.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "mengw15 (via GitHub)" <gi...@apache.org>.
mengw15 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5478342862
A product-design question on the gating model, raised while reviewing formview-pr2 (the answer bears directly on that PR's column and endpoints, and on pr8a/pr11 later, so worth settling before more slices land):
Right now Form View is a per-workflow capability the author must switch on, and the form page redirects away when the workflow isn't marked. An alternative model: the form is always available for every workflow — with zero exposed inputs it degrades to a one-click run page (Run + results), and exposed bindings only enrich it. That removes the empty-page problem the flag guards against (the page always has at least Run + results), dissolves the enable-before-authoring bootstrap, and gives read-only visitors a coherent run-only surface instead of needing a redirect. The per-workflow bit could then shrink from a capability gate to a default-entry preference (open in form vs canvas by default) — or disappear entirely: the landing view can be derived from whether the content carries any bindings, if the dashboard doesn't need to mark form workflows without reading their content.
A concrete simplification: the gate currently has to be inherited along every copy path (duplicate, hub clone, and version clone — where the flag isn't versioned, so a version clone gets today's setting regardless of the content it restores); in the always-available model those questions don't exist.
The open questions this model has to answer: what an un-curated form shows in its results area (default to the operators already marked for result viewing?), and whether a run-without-context page should be reachable on every workflow at all (the current flag also doubles as the author's "this is sensible to run as a black box" signal). Curious whether you considered this shape.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "yangzhang75 (via GitHub)" <gi...@apache.org>.
yangzhang75 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5482541641
> Read through the series (and the `formview-mvp` branch) ahead of reviewing the PRs. Three design-level points, raised here once rather than piecemeal on the slices:
>
> **1. agent-service will erase the form definition on save.** `agent-service` keeps its own copy of `WorkflowContent` (`agent-service/src/types/workflow.ts`) and rebuilds the content object from that allowlist before POSTing `/workflow/persist` (`workflow-state.ts`, `getWorkflowContent()`). Any agent edit to a parameterized workflow drops `parameterization`, while `is_parameterized` stays on — the form becomes an empty shell. The same copy already lacks `settings.executionMode`, so an agent save silently resets the execution mode today. The plan probably needs an agent-service slice (or fold it into formview-pr3).
>
> **2. The read-only path needs an explicit decision.** For a user with READ access, the MVP form is fully editable: the input cards are standalone form groups not covered by the modification lock, so typed values go into the shared-editing doc (co-editors see them live), every autosave is then rejected by `/workflow/persist` with 403 and surfaces the "Could not save" toast on each debounce, and Run still works because execution is gated on computing-unit access rather than workflow access. This path is reachable from the normal UI: the dashboard entry-link rewrite and the form page's redirect both check `formViewEnabled && isParameterized` but not `readonly`, so a workflow shared read-only (or any public one, since `hasReadAccess` is true for those) opens straight into it. Worth deciding once at the design level — redirect read-only users to the canvas like the flag-off case, render the inputs read-only (view and run with the stored values), or scope the form to write-access us
ers for the first release.
>
> **3. Question, not blocking: why an `is_parameterized` column instead of deriving from content?** The single-workflow paths don't need it — `retrieveWorkflow` returns the content, and the form page already redirects based on the loaded workflow. The column seems load-bearing only for the dashboard listing affordances (icon, entry-link rewrite, list-page toggle), since listings don't select `content`. If that is the rationale it's a reasonable trade — worth recording it in formview-pr2 together with the cost it imposes on `/persist` (the extra fetch-before-update needed so a plain save doesn't reset the flag).
1. Good catch, and agreed it belongs with the types slice. It's handled in #8275 (formview-pr3): rather than add `formBinding` to agent-service's typed allowlist, `WorkflowState` carries it as an opaque value, capturing `content.formBinding` on load and re-emitting it in `getWorkflowContent()` on save only when the loaded content actually carried one. A plain workflow's serialized content therefore stays byte-identical (no `"formBinding": null` creeps in) while a form workflow survives any agent edit intact, and because it's opaque, later shape changes to the definition need no agent-service change. It's covered by a test, `carries the Form View definition through an agent save untouched`. The `settings.executionMode` drop you noted is a real but separate, pre-existing issue, since agent-service's `WorkflowSettings` type only declares `dataTransferBatchSize`, so I'll file it on its own rather than widen this slice.
2. Agreed this needs deciding once. Decision: render the inputs read-only for read-access users (your middle option), i.e. view the stored values and run, with no redirect. Concretely the form inputs will subscribe to the same `getWorkflowModificationEnabledStream()` the property editor already uses, so they render disabled for a read-only user exactly the way operator properties do on the canvas. That closes the gap you identified, since the input cards are standalone form groups today that sit outside the modification lock, and it removes the 403-on-every-debounce loop at the source, because with no editable values there is nothing to autosave and `/workflow/persist` is never called. Run still works because execution is gated on computing-unit access, so a read-only or public workflow opens into a coherent view-and-run surface that behaves just like the read-only canvas.
3. Yes, that's exactly the rationale. The dashboard listing and search paths deliberately don't select `content` (it's a large blob), so anything the listing needs, such as the icon, the entry-link rewrite, and the list-page toggle, has to live on the workflow row rather than be derived per-item from content. It's the same reason `is_public` is a column, and the form-view bit is a natural peer of it. On the `/persist` cost you flagged, it's already avoided in #8125 (formview-pr2): `saveWorkflowFields` issues an explicit-column UPDATE of just `name`, `description`, `content`, and `is_public` and never writes the form-view column, so a plain save leaves it untouched with no fetch-before-update, since that column is owned solely by the toggle endpoint. I'll record this rationale in the PR description as you suggested. Forward note: per the gating-model thread this column is becoming a `default_view` preference (canvas or form) rather than a capability flag, but the column-vs-derive r
easoning is unchanged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "yangzhang75 (via GitHub)" <gi...@apache.org>.
yangzhang75 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5432521201
/take
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] Form View: a form-based view for running a parameterized workflow [texera]
Posted by "yangzhang75 (via GitHub)" <gi...@apache.org>.
yangzhang75 commented on issue #8011:
URL: https://github.com/apache/texera/issues/8011#issuecomment-5483013732
> A product-design question on the gating model, raised while reviewing formview-pr2 (the answer bears directly on that PR's column and endpoints, and on pr8a/pr11 later, so worth settling before more slices land):
>
> Right now Form View is a per-workflow capability the author must switch on, and the form page redirects away when the workflow isn't marked. An alternative model: the form is always available for every workflow — with zero exposed inputs it degrades to a one-click run page (Run + results), and exposed bindings only enrich it. That removes the empty-page problem the flag guards against (the page always has at least Run + results), dissolves the enable-before-authoring bootstrap, and gives read-only visitors a coherent run-only surface instead of needing a redirect. The per-workflow bit could then shrink from a capability gate to a default-entry preference (open in form vs canvas by default) — or disappear entirely: the landing view can be derived from whether the content carries any bindings, if the dashboard doesn't need to mark form workflows without reading their content.
>
> A concrete simplification: the gate currently has to be inherited along every copy path (duplicate, hub clone, and version clone — where the flag isn't versioned, so a version clone gets today's setting regardless of the content it restores); in the always-available model those questions don't exist.
>
> The open questions this model has to answer: what an un-curated form shows in its results area (default to the operators already marked for result viewing?), and whether a run-without-context page should be reachable on every workflow at all (the current flag also doubles as the author's "this is sensible to run as a black box" signal). Curious whether you considered this shape.
Thanks for raising this before the later slices. The always-available shape is a reasonable model and its simplifications are real: it removes the empty-page guard, the enable-before-authoring bootstrap, and the copy-path inheritance including the un-versioned version-clone case. I did weigh it, and on balance I lean toward keeping the per-workflow gate, mainly for a UX reason.
It comes down to the three audiences. The author enables Form View and builds the form; the reader clones a published form and uses it, without enabling anything themselves; and most users only work on the canvas and do not need a form at all. Only the author asks for a form, and enabling is meant to be their action rather than the reader's. In the always-available model that third group, which is the majority of workflows, gets a form tab and a run-only page on workflows no one authored a form for. For a canvas user that is extra surface they did not ask for, and it makes the form feel like a property every workflow has rather than something an author chose to build. Keeping enabling as a small, one-time author action seems a better trade than adding that surface everywhere.
Where the two models actually differ is only in what "off" means. In the always-available model an off workflow still has a reachable form, with canvas as the default landing; in this model off means the workflow offers no form at all: no tab, no run-only page, canvas only. That is the distinction the decision rests on, since it is what keeps canvas-only workflows unchanged. Given two states, the bit stays a boolean is_form_view; a default_view enum is not needed, as "on" already implies it opens in its form.
On the specific concerns within this model. Copy paths: the flag traveling on duplicate and hub clone is intended rather than a cost, since it is what lets a reader clone a published form and use it without enabling. Version clone: cloneVersion takes content from the chosen version but the current is_form_view for the new workflow; I would keep that and note it as deliberate, since form status is a current property of the workflow rather than something stored per revision. Empty page: the only window for it is during authoring, and a published form has bindings; the entry point can require at least one binding if we prefer, but I would not let that edge case drive the model. Read-only visitors: handled by rendering the inputs read-only, using the same modification-enabled stream the property editor already uses, so a read-only or public form opens into a view-and-run surface with no 403-autosave loop and no redirect, consistent with the read-only canvas.
On the open questions: for an un-curated form's results area, defaulting to the operators already marked for result viewing sounds right. And a run-without-context page should not be reachable on every workflow, which is what the gate provides: only a workflow the author marked as a Form View exposes that surface.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@texera.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org