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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
