Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

render-seq-generic strange behaviour for "text/html" "text/plain" "text/csv" #297

Open
petoalbert opened this issue Jun 4, 2018 · 1 comment

Comments

@petoalbert
Copy link

Lets take the following resource to demonstrate the problem:

(defresource my-resource
  :available-media-types ["text/plain" "text/html" "text/csv" "application/json"]
  :available-charsets ["utf-8"]
  :handle-ok ["wow" "cool"])

It works fine for "application/json", but accessing it as "text/plain" leads to the following exception: nth not supported on this type: Character

With "text/csv" and "text/html", I get this: java.lang.Character cannot be cast to java.util.Map$Entry. If I get it correctly, this is caused by the implementations of render-seq-generic trying to interpret their data argument as a sequence of Maps for these MIME types, but I cannot imagine why.

For example, render-seq-generic for "text/plain" directly calls render-map-generic on the sequence items:

(defmethod render-seq-generic "text/plain" [data context]

Can somebody explain to me what the representations for these MIME types are intended to look like?

FYI: I discovered this by running the examples from the project and accessing athletes-resource at /drag-drop/athletes

@vidraj
Copy link

vidraj commented Mar 10, 2021

The HTML, CSV and TSV rendering provided by render-seq-generic is meant to represent a table of (named) values, so the sequence should look like [{:reaction "wow" :attitude "cool"} {:reaction "nope" :attitude "cool"} {:reaction "haha" :attitude "pleased"}], resulting in the following CSV:

reaction,attitude
wow,cool
nope,cool
haha,pleased

All maps should have identical keys, or at least the keyset of the first element in the seq should be a superset of the rest, otherwise the headers will be broken.

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

No branches or pull requests

2 participants