widdershins output does not include parameter collectionFormat/array style information

[DavidBiesack]

If a parameter type is an array with collectionFormat: (OpenAPI 2.0.0) or style: (OpenAPI 3.0.x), the output does not describe the format or string delimiter (comma for default, or | for pipes, etc.)

Input OpenAPI 2.0 and 3.0 attached.

openapi2.yaml.txt openapi3.yaml.txt

[MikeRalphson]

By output, do you mean the representation of the parameter in code samples?

[DavidBiesack]

It is not represented anywhere. I'd like to see it in the table that describes the parameters. It is just defined as array[string] The code samples do not show parameters.

[MikeRalphson]

Ok, we're very constrained for space in the tables such as that for parameters. Any ideas for how to represent things would be gratefully received.

My comment about code samples referred to required query parameters, which do get included (in some templates).

[DavidBiesack]

We have our own custom templates for parameters, so I can add include {{p.style}} in our layout. (We use a simpler two columns, Name in the left column, with optional <br>(**required**) if required, and Description column that contains the type `
description
constraints like minimum/maximum/readOnly, etc. so we can include the style with the other parameter metadata there.

For the generic case, I suggest augmenting the type column in parameters.def from array[string] to include the style after {{p.safeType}} such as one of

array[string]<br> style: pipeDelimited
array[string]<br> style: spaceDelimited
array[string]<br> style: simple

(maybe omit if it is the default form style??) You could insert a newline to keep the column narrower, since the param description often causes the parameter row to fold over multiple lines anyway.

[MikeRalphson]

Hmm, good thoughts. I'd like to avoid leaking direct OpenAPI terminology such as style and explode though and make it more descriptive or use an example or links.