Automatically determine common content types for user input provided in interact steps

[olw-medcom]

Hey there,

We have a MULTILINE_INPUT where users can either insert xml or json content (and in theory a lot of other things as well). When we review their test case and click on the step where they have provided it we have the option to download it as a file, but it's always downloaded as a .txt file. I was wondering if you could make some logic on your side that tries to estimate the filetype? For example if it starts with a < it's most likely a .xml file and if it starts with a { it is most likely a .json file

I'm not sure where, but I have a feeling that you've changed the filetype automatically elsewhere in the ITB? Not sure about this but it would be a nice quality of life feature for sure ^_^

[costas80]

Hi @olw-medcom. When an input is defined as MULTILINE_INPUT then indeed it is considered as plain text and gets display and downloaded as such.

Why not use a CODE input for this? Its a lot better for something like what you describe and it takes a mime type that will define syntax highlighting. In addition, if set this also affects the name of the file being downloaded (e.g. if you set the input as application/xml then it will download as [NAME].xml).

I was wondering if you could make some logic on your side that tries to estimate the filetype?

Ouf, that sounds like overkill. The problem is not necessarily the estimation, its that you are asking that this is applied to a MULTILINE_INPUT which we consider as basic text. We definitely don't want to do on-the-fly content type determination for all text inputs :) (hence my suggestion to use CODE and to set yourself the mimetype you expect)

P.S: You could also ask the user what mime type they are providing by e.g. listing the options you support in a dropdown? Just an idea :)

[olw-medcom]

Why not use a CODE input for this

Because we would like multiline input instead of just a single line. I'm under the impression that CODE is only one line? Maybe I'm wrong on this

You could also ask the user what mime type they are providing by e.g. listing the options you support in a dropdown? Just an idea :)

I don't really like the idea of giving the user more things to fill out everytime when it's so simple for us to programatically figure out. Is there any way that we can do this programatically, making the choice between xml and json?
Another thing about doing it programatically instead of choice-based is that then we won't have user input error where they put it as json even though it was actually xml

[costas80]

Because we would like multiline input instead of just a single line. I'm under the impression that CODE is only one line? Maybe I'm wrong on this

Setting CODE gives you a full code editor (multiline of course) also with syntax highlighting if you specify it. The single line text is when you set an input as TEXT (see here). So using CODE is definitely the way to go here and I would use MULTILINE_TEXT only for something like a long description.

Is there any way that we can do this programatically, making the choice between xml and json?

Sure, why not? As a first step show an interact with a CODE input for the user to provide the info (no need for extra dropdowns and choices here). Then use an assign step that determines the mime type from the provided content as such:

<!-- Note: didn't try this so treat it as something to potentially tweak. -->
<assign to="inputType">if (starts-with(normalize-space($data{input}), '{')) then 'application/json' else 'application/xml'</assign>

And then when you display the input set its mime type accordingly (on another interact or a process with DisplayProcessor).

[olw-medcom]

Setting CODE gives you a full code editor

Ahh okay, I've played around with it now and understand why I was confused earlier, the "size" attribute is for the CODE pixels and not amount of lines.

And then when you display the input set its mime type accordingly (on another interact or a process with DisplayProcessor).

Hmm but I would rather have it on the first interact step. Otherwise it becomes unintuitive to open another step just to download it

[costas80]

Hmm but I would rather have it on the first interact step. Otherwise it becomes unintuitive to open another step just to download it

Hmm, so to understand better what you're going for you want to:

• Show an interact with an editor that users enter text-based content (can be JSON or XML).
• You then want that the report for this specific interact step infers the content/mime type from the provided content so that (a) the content is syntax-highlighted correctly and (b) the downloaded file is a JSON or XML file.

Is this more/less what you have in mind?

[olw-medcom]

More or less, yes, the (a) syntax-highlighting is not important for us in this context ^_^

[costas80]

I'll try to see if we can do this. We already have a "default" case processing textual content for which the content type is not determined which leads to the "fileName.txt" download you currently see. I think we could inject in there logic whereby (a) if the provided content type is not declared/determined, and (b) the content is definitely text-based, we do a lightweight and best-effort content type determination on the fly (along the lines of what the assign step I used in the example does) with the goal of identifying common textual syntaxes (XML and JSON for sure, possibly also YAML and common RDF types).

I'll look into this and let you know!

P.S: I'll take the liberty of renaming this issue to make it more clear.

[olw-medcom]

That sounds really good, thank you @costas80!

[costas80]

Hey @olw-medcom ! The requested update is now available to pull through the latest nightly build. In brief, whenever viewing or downloading text content without having explicitly specified the content type, we do a quick check in the content to see if it matches common patterns for JSON and XML (the most commonly used syntaxes). This applies both to the downloaded file as well as the in-editor display.

Can you confirm when you've had a chance to pull and check on your end?

[olw-medcom]

That was swift!
Thank you! I unfortunately will not be able to test it because I'm going on vacation currently and I can't restart the ITB to get the update today as we have some pending admin interactions that would break if I shut it down.