Skip to content
This repository has been archived by the owner on Dec 7, 2023. It is now read-only.

Support "bulk input" (multi-line) variables #16

Open
JeanMertz opened this issue Jun 14, 2019 · 0 comments
Open

Support "bulk input" (multi-line) variables #16

JeanMertz opened this issue Jun 14, 2019 · 0 comments

Comments

@JeanMertz
Copy link
Contributor

JeanMertz commented Jun 14, 2019

Right now, a pipeline variable automatically becomes an input form field in the web-client pipeline view:

Screenshot 2019-06-14 at 09 01 02

But there are pipelines that become more usable if they'd support some kind of "batch input" process.

One example would be to allow people to copy rows from a spreadsheet, and paste them into a text field. The processors handling this could then do their thing based on newlines in the input, and handle each line as needed.

There is no need for special treatment of this data in the processors themselves, it's simply something you take care of when configuring the processor. For example the shell-command processor could deal with newlines in whatever way is needed by using the proper Unix utilities.

So, I propose we allow some kind of flag to be set for variables to let the clients know to special-case these variables to be shown like this (in case of the web-client, using a textarea form field):

Screenshot 2019-06-14 at 09 06 32

One way to do this, would be to make this change:

struct Variable {
    key: String,
    description: Option<String>,
+   multi_line: bool,
}

In the server's GraphQL interface, we'd make this field optional, and default it to false.


Another solution would be to actually start using variable types for this, not too different from how you'd use varchar and text in SQL:

+ enum Type {
+     String,
+     Text, // to be bikesheded
+ }

struct Variable {
    key: String,
    description: Option<String>,
+   type: Type,
}

This approach seems more flexible, and more future-proof, as it would eventually allow us to natively support boolean variables (which the web-client could them interpret as a checkbox field), and others, which is on the long-term roadmap, but perhaps there are downsides to this that I haven't considered yet.

Similar to the other solution, in the GraphQL interface I would make the type input field optional, and default to String, as that's the most common case.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant