You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To flexibly handle all input types for a model (static fields, transforms, document fields, templates, etc.), we can have a more structured UI for configuring. The current UI just allows freeform text or a dropdown of available fields, if found. In the end, it is all converted just to text anyways. Below are some of the target mockups highlighting the different input types we should explicitly show:
To accomplish this, we will need to do the following:
update the underlying UI config for input transforms - we need to persist some metadata determining the different "types" offered (template vs. document field etc.) Support different input transform types #495
add abstraction logic to convert constants/templates into the model_config field for the ML processor when converting to a final template containing the JSON config body, and leaving document field / transform definitions as values for the input maps Support different input transform types #495
finalize what will be done for the outputs - do we duplicate some of the logic? The key difference is static values will not be supported - only JSONPath / selecting fields from the model output will be supported. Support different output transform types #502
The text was updated successfully, but these errors were encountered:
A small adjustment to UI for Prompt and Expression:
For initial state, we can remove the pencil icon in the "Configure" button. Click on the Configure button will open the prompt/expression modal.
For the inputted state, we can use plain text and the pencil icon. Clicking on the pencil icon will open the prompt/expression modal. The read only text field may confuse users into thinking it can be editable inline.
To flexibly handle all input types for a model (static fields, transforms, document fields, templates, etc.), we can have a more structured UI for configuring. The current UI just allows freeform text or a dropdown of available fields, if found. In the end, it is all converted just to text anyways. Below are some of the target mockups highlighting the different input types we should explicitly show:
To accomplish this, we will need to do the following:
model_config
field for the ML processor when converting to a final template containing the JSON config body, and leaving document field / transform definitions as values for the input maps Support different input transform types #495The text was updated successfully, but these errors were encountered: