(defmethod shape-to-spec “list” [ns [name {{:strs [shape]} “member” :strs [max]}]]
`(spec/and
(spec/coll-of ~(keyword ns (aws/dashed shape)) :max-count ~max)
(spec/conformer identity #(if (sequential? %) % [%])))) ; HAL ❤
this conformer is a case of protocol leak
HAL allows to replace single-item lists by just the item
of course you see that it’s in the “unform” direction
conform is from edn to payload and unform from payload to edn
I’d like to get rid of all conforms because I want specs to work first as a clean documentation.
I don’t want to muddy this with protocol details
so in gen-api
I make provision for some vars (prefixed by ser-
deser-
req-
and resp-
followed by a spec name), they are expectd to be populated by functions doing transformations.
right
obviously these fns would be protocol-dependent
so for example for rest-xml, xml would be serialed/deserialized with these fns
maybe not entirely
the core fn would be rest-xml-call
, it could do the generic xml lifting
req-
resp-
could work from the request/respoinse maps with parsed bodies
and ser-
deser-
do the local transformations
example of local transformation: turning a <list>
tag into an actual list
ah, true
so while making a call, the data that is fed to say ser-create-function-request
would be checked against a spec?
Yes
1/ call conform or valid
2/ call req<-create-function-request
-- it indirectly calls some ser-stuff
to performs coercion and small fixes
3/ serialize the body of the request in the *-call
fn
thinking about pagination
at least one can grab token from response and use it for next request
hey, @cgrand I am going to look at your wip next monday
did not have the time last few days
hmm master...
I think I've formed some obstacles in form of merge conflicts if thinking of rebasing the wip
You are too impatient Grasshopper