yangzhang75 commented on code in PR #8843:
URL: https://github.com/apache/texera/pull/8843#discussion_r4199148654
##########
frontend/src/app/workspace/util/custom-formly-type.ts:
##########
@@ -21,18 +21,18 @@
* Widget types that cannot be a form field at all, so the property is not
offered for exposure on
* the Form View. Only the code editor: editing code is not "filling in a
value", and a form reader
* should not be writing code. (A drag-reorder property such as Projection's
columns stays exposable
- * -- it just renders without the drag in the form -- so it is deliberately
NOT in this set.)
+ * and renders with its drag in the form, so it is deliberately NOT in this
set.)
*/
export const NON_FORM_FIELD_TYPES: ReadonlySet<string> = new Set(["codearea"]);
/**
* Widgets that only work on the operator canvas, so the Form View does not
render them: it falls
- * back to formly's default control instead. The code editor (also blocked
from exposure by
- * {@link NON_FORM_FIELD_TYPES}) and the drag-reorder list, whose drag has
nowhere to attach on a
- * form -- a workflow may still carry an exposed drag-reorder property from
before, and it degrades
- * to a plain editable list rather than a control that cannot function here.
+ * back to formly's default control instead. Only the code editor (also
blocked from exposure by
+ * {@link NON_FORM_FIELD_TYPES}), which opens into an outlet the canvas owns.
The drag-reorder list
+ * used to be here too, as if its drag had nowhere to attach on a form; it
carries its own drop
+ * list, and renders on the form with the drag, as on the panel (#8761).
*/
-export const CANVAS_ONLY_FORMLY_TYPES: ReadonlySet<string> = new
Set(["codearea", "repeat-section-dnd"]);
+export const CANVAS_ONLY_FORMLY_TYPES: ReadonlySet<string> = new
Set(["codearea"]);
Review Comment:
Not doing this one, and the issue text is the reason it reads as required --
I wrote that line into #8761 myself and it has been dropped. The canvas's own
drag-reorder widget has no Move up / Move down path either, so adding one here
would be a new capability on both views rather than rendering the existing one
on the form, which is what this issue asks for. A keyboard path for reordering
belongs in its own issue, covering the canvas and the form together; #8761's
text is being corrected so it stops asking for it here.
--
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]
