yangzhang75 opened a new pull request, #8848:
URL: https://github.com/apache/texera/pull/8848
### What changes were proposed in this PR?
Closes #8847. The Python UDF operator's "UI parameters" table (#5043) infers
each parameter's name and type from the `self.UiParameter(...)` declarations in
the operator's code, so the widget disables those two columns' controls as it
builds each row: a name typed into the table does not reach the code, and the
parameter's value then never reaches it either (checked on main: the table's
name changes, the code's does not).
The lock does not survive on the operator property panel.
`setInteractivity(true)` enables the whole form group -- one task after every
render, and again whenever the workflow becomes modifiable, for instance when a
run ends -- and formly mirrors a control's state back into `props.disabled`, so
the one-time disable is simply undone. Which state a given panel opening shows
depends on which of the two ran last: measured on main, the cells were editable
on 4 of 5 openings, and always after a run. The Form View, which never enables
a group wholesale, has always shown them locked, so the two views disagreed as
well.
The widget now holds its own lock. On each cell it locks it registers
Angular's disabled-change hook of the control (`registerOnDisabledChange`, the
same hook formly's mirror and the input's value accessor use): when a host
enables the control, the hook disables it again in the microtask after that
enable, and announces the status change as the enable did. Both details matter
and were found on a running instance:
- deferred to the microtask, because the input's value accessor is one more
hook on the same control, registered after this one when the cell renders;
disabling from inside the enable's own round of hooks left the accessor having
been told "enabled" last, so the box was editable over a locked control;
- announced rather than silent (`disable()`, not `disable({emitEvent:
false})`), because ng-zorro's `nz-input` paints its `disabled` attribute from
the control's status changes; a silent disable left it painting the box
editable again at the next change detection.
A cell the widget configures editable -- the Value column, or any cell once
reconfigured -- is released from the hold, so whether it is editable stays the
host's call: a read-only panel still locks everything, and a host that disables
the whole field still reaches the Value cell. The frame is untouched: two other
approaches were tried first and dropped, re-disabling from the frame after
`enable()` (formly's mirror has already set `props.disabled` to false by then)
and a formly expression on `props.disabled` (formly re-evaluates expressions on
model changes only, and registers them at populate, so `enable()` never
triggers one).
### Any related issues, documentation, discussions?
Closes #8847. Split out of #8846 (the same table under the Form View's
renames and hides), which is based on main and does not touch this; the two are
independent and can land in either order. The table's fixed 250px columns clip
Name and Type at the panel's default 260px width, which is why the cells have
to be brought into view to see any of this; that is a separate layout bug,
filed separately.
### How was this PR tested?
Unit tests (vitest). The widget's spec: a locked cell's control is held
locked when a host enables it, in the microtask after the enable and announcing
the status change, while the Value cell is left to the host; a cell configured
editable again is released from the hold; a cell the host disables again before
the microtask is left alone; a control that is not a `FormControl` gets no
hook, and a control is hooked once however often it is configured. A second
spec stands the table up under real formly (`FormlyModule.forRoot`, a form, the
builder row template formly-jsonschema produces, `nz-input` cells as in the
app): the rows build with Name and Type locked and Value editable; a wholesale
`form.enable()`, as the panel does, leaves Name and Type locked, read from the
inputs' `disabled` state and not only from the controls'; a read-only
`form.disable()` locks everything and a later `enable()` gives only the Value
cell back. Each guard was deletion-checked and turned a named test red.
eslint, prettier and the production (AOT) build pass; the full frontend suite
passes; every statement, function and branch this PR adds is covered.
Checked on a local instance (a Python source feeding a Python UDF whose code
declares two UI parameters), the panel widened so the columns are in view. On
main the cells are editable on most openings (4 of 5) and after every run; with
this PR they stayed locked on every opening and through a forced
`setInteractivity(true)` followed by real change-detection passes, read from
the DOM as well as from the controls. The Value cell follows the host in both.
#### Video
**Before**
_(to be added)_
**After**
_(to be added)_
### Was this PR authored or co-authored using generative AI tooling?
Yes. Generated-by: Claude Code (Anthropic). Co-authored with Claude,
reviewed line by line by the author before submission.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
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]
