GitHub user sshiv012 edited a comment on the discussion: UX Feedback (Operator
Descriptions)
Text Input is a good candidate because its current description, “Source data
from manually inputted text,” omits behavior that changes the output shape. The
implementation produces one tuple containing the complete input for single
string; otherwise, i believe it iterates over lines, applies offset/limit, and
parses each line as the selected attribute type. A more useful description
could be:
“Creates tuples from manually entered text. Single String emits the entire
input as one tuple; other attribute types emit one parsed tuple per line.
Offset and limit select which lines are emitted.” Or more generally, operator
descriptions could follow a small template: input unit, output unit, important
mode-dependent behavior, and failure conditions. I am thinking if we can build
a backwards compatible template, kinda representing the above like optional
structured field here,
```scala
case class OperatorDocumentation(
summary: String,
inputUnit: Option[String] = None,
outputUnit: Option[String] = None,
behavior: List[String] = List.empty,
failureConditions: List[String] = List.empty
)
```
Based on my inspection, OperatorInfo currently exposes one free-form
operatorDescription string, which the frontend renders directly. The UI could
render the summary in the existing tooltip and show the remaining fields in an
expandable details section. Keeping the field optional would allow operators to
migrate incrementally while preserving existing descriptions. Operators could
adopt it incrementally without rewriting every description at once. Would a
structured, optional template fit the intended scope of this proposal?
GitHub link:
https://github.com/apache/texera/discussions/6798#discussioncomment-17743378
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
