Jump to content

Pre-populating a Text View's Script Input field with an initial value

Recommended Posts



Is there a way that a Text View's Script Input (the input field that can be shown above/below the response) can be pre-populated with some default value? As it stands currently, it seems the script input is always blank by default.


I know I can populate the response of a Text View with whatever I want using the "response" key (per the docs), but I am talking about populating the optional input field with a default/initial value when the Text View first renders.



Edited by caleb531
revising title to be clearer
Link to comment
Share on other sites

  • caleb531 changed the title to Pre-populating a Text View's Script Input field with an initial value
12 hours ago, caleb531 said:

would need to pass a variable (e.g. {var:default_text}) as that initial value of the input.

Why not use an Arg and Vars Utility to send that as a query? That’s what the ChatGPT / DALL-E workflow does.


Extending the JSON doesn’t really seem like it’d solve what you want, from the description. What’s the use case for populating the input field instead of directly doing the thing?

Link to comment
Share on other sites



I tried the Arg and Vars utility per your suggestion, which I can certainly use to populate the "response" key in the Text View JSON that my script outputs. However, that's not the issue. I'm not talking about populating the main body of the Text View (that works fine). I'm talking about populating the user input field with a default/initial value (e.g. in the case of the ChatGPT workflow, this is the input you can type questions into). Populating an arg on my result being fed into the object seems to have no effect on the value of this field.


Use Case


My use case is this: I workflow offers a number of different formats for the user to choose from. Each format determines how the contents of a Bible verse will be structured. Currently, all of the formats are predetermined and cannot be edited. But I want to give the user the ability to edit any of these formats.


To do this, I was thinking of letting the user choose a format from the result list I already present to them. Upon choosing a result, the user would be taken to a Text View with the raw format string pre-populated in the Script Input (this is what I am unable to do), and the main response of the Text View showing a preview of how the format will render (which works fine by itself).


Please see my attached screenshots.



Link to comment
Share on other sites

I see, thank you for explaining. Just offering another alternative here: have you considered making the Text View text editable? That way users can edit the text in place. It seems more straightforward than having to know the specific syntax to input in the box.

Link to comment
Share on other sites

@vitor I have at least considered that, although depending on how they edit the preview, it may not be clear how to derive the new format string. My hope is that because the Script Input and the Text View response are both displayed as separate things, that I could allow them to edit the format string and see a live preview of how it would render out. It would be the best of both worlds. And if they enter an invalid syntax for the format string (within the Script Input field), then the Text View response body would display an appropriate error message in place of a rendered preview.


But you still make an interesting argument. If I relinquish my need for a preview, I could render the format string into the Text View response body in Editable mode. Then I could perhaps use the footer text to render out any error messaging. I will look into this. Thank you!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...