@malcolmsparks: Perhaps there should be a record which designates that encoding has been taken care of? That would clearly separate the two use cases.

@dominicm But what if the user formatted the json outside of yada?

@malcolmsparks: Then they'd take that string, put it in (TakenCareOf my-formatted-json) and that would be the return value.

And then use a multimethod to pick up the TakenCareOf record, and skip over formatting.

Or am I misunderstanding?

Yes, they could wrap in a JsonString record. There's a design choice that will work. But it's a hassle for those who have to remember to wrap in JsonString. What Would Rich Do?

Jump in a hammock, but I don't have one.

I mean, the way you want to handle it is going to vary from case-to-case: Currently: Want to JSON encode yourself: (json-encode my-map) Want to JSON encode a map: my-map Want to .. a string: (json-encode string) JsonString: encode yourself (yada/json-string (json-encode my-map)) a map: my-map a string: string

I feel like always encoding primitives makes more sense in a consistency pov.

But the overhead would need addressing somehow. Whether that is encouraging that custom json-encode functions are written, or something else, I don't know.

;; Example encode
(def json-encode (comp yada/json-string some-lib/json-encode)

Simple, and Easy.

Upsides: auto conversion of a string to a JSON string. Downsides: Unpleasant surprise for a diligent developer already 'doing the right thing' of using a json library to encode the string and declaring the mime-type correctly.

It doesn't sit easy with me

If the developer returns a clojure sequence or map then it's obvious that yada should encode that to json. But the string is much more problematic for me. I feel yada should get out of the way in such cases.

Even if there is a workaround to 'tell' yada to get out the way, the developer might not be aware of it at the time of the unpleasant surprise. So it's not intuitive - the developer must guess that this feature must exist and resort to stack overflow to find out

I'm not saying you're wrong of course :)

I just have concerns that we need to think through in the hammock

I do acknowledge that the status quo isn't ideal either. A user-agent will try to parse a json string which turns out to be textual error message. JSON parser blows up. It's a problem, yes.

I used to have a hammock tied across two trees. I have since moved to a new place where tree distances do not allow for a hammock. More's the pity.

I shall have to buy a ugly hammock stand from ikea :(

No no, they're good points. We're at the point of guessing human nature and usage. I need to review the docs for the current version to see what "feels" natural. But I'm already cursed by knowledge.

Could a solution be : put in :body things that are to be coerced, otherwise put them under another key, like :raw ?

@nha that idea has legs

@nha that's an interesting idea

Thanks

I have no idea how it affects yada protocols, and it would also have to be clear that one cannot fill both though.

:raw doesn't feel exactly the right kw but close

Yes I still have some work to learn to name things ^^

Naming is hard :)

One of the two hard things in comp. sci

Yes

There's a similar feature in yada today where you can return the (:response ctx) perhaps modified and yada should then step aside

It's a way to say to the method proxy "this is the actual response I was to return, leave it alone!"

Well I was not aware of any other ? I use it like :

(-> (:response ctx)
            (assoc :status 202)
            (assoc :body {:a-key "a-val"}))

It does incur overhead for all responses though. Given the coercive nature of yada, I see the dilemma a little better now.

Yeah, you could just return

{:a-key "a-val"}

Yada's method 'proxy' would put in the 202

Each method has a proxy to codify the semantics

It's a design I'm quite pleased about

Looking through the docs, if I had to support html, I think I'd go with my own resource type, which understood json/edn conversion of itself. It's similar to my own internal version of coercion I've come up with.

(defrecord Cloak
  [template data]
  JSON
  (json-encode []
     (default-action data))
  EDN
  (edn-encode []
    (default-action data))
  HTML
  (html-encode []
    (html/template template data)))

Then my handlers would just return a Cloak record.

That's very neat ! However if I return

{:a-key "a-val"}

java.lang.IllegalArgumentException: No implementation of method: :interpret-post-result of protocol: #'yada.methods/PostResult found for class: clojure.lang.PersistentArrayMap

using [yada "1.1.0-20160114.191215-6"]

if I do (yada {:a-key "a-val"}) I get

java.lang.IllegalArgumentException: No implementation of method: :interpret-post-result of protocol: #'yada.methods/PostResult found for class: yada.handler.Handler
	at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:554)
	at yada.methods$eval51720$fn__51721$G__51711__51728.invoke(methods.clj:194) 

@nha - yeah, it's only on GETs right now.

I will add the same thing to other methods though

sorry, forgot to mention that