hi there - i’m having a go at writing my own contract renderer, but most of the fields/methods on Co...

# http4k

[Tom Ellis]

hi there - i’m having a go at writing my own contract renderer, but most of the fields/methods on ContractRoute are internal meaning you can’t really get the info from the routes. Is there a particular reason for this? is it possible to relax these?

[Tom Ellis]

the contract route meta also currently provides a way to override the definition id - but could it be possible to provide a way to override the schema generation (the asSchema method of HttpMessageMeta) of a request/response as well?

[dave]

There isn't a particular reason for these being internal, other than encapsulation to minimise the API surface. Obviously we want people to be able to implement their own renderers, so we can open them up no problem.

[dave]

@Tom Ellis Regarding asSchema(), can you clarify? The implementation of that extension method is entirely private inside OpenAPI, so I think it may be entirely irrelevant if you're implementing your own Renderer

[Tom Ellis]

for my renderer, i’d like to retain the parameter/response example/object type so i can generate the schema with the correct names - at the moment because when using `receiving`/`returning` the lens is immediately applied to the example to get json and put it in the request/response, it loses that information. it seems that’s also why the current OpenAPI renderer generates object names with object-$hash. We can’t use this as clients want to generate libraries using the swagger json, and the names that get generated obviously don’t play nicely with that

[Tom Ellis]

i guess i could add the example as a header on the Response/Request object when creating a ResponseMeta to pass it down

[dave]

this is going to definitely be a bit trickier, as the definition of the ResponseMeta is totally disconnected from the Schema generation.

[dave]

one option would be to unseal the HttpMessageMeta class and allow you to define your own implementation which had this option

[dave]

(which is specific to your renderer)

[Tom Ellis]

yeah i thought about that too

[dave]

the problem is that the JsonSchema generation as it stands won't help because it works on a JSON document and generates names for all the child-fields

[Tom Ellis]

yes

[dave]

so you're going to have to generate a schema based on the example kotlin class

[dave]

(if you want to retain names)

[Tom Ellis]

yeah i think we’re ok with that

[dave]

ok - I'll unseal the HttpMessageMeta then

[Tom Ellis]

thanks!

[dave]

I was about to push out a release anyway today.

[Tom Ellis]

oh nice! great timing 😄

[Tom Ellis]

thanks so much

[dave]

releasing 3.129.0 now - all being well it should hit jcenter in 30, then maven in a couple of hours 🙂

[Tom Ellis]

hmm - `receiving`/`returning` actually takes ResponseMetas which i obv can’t extend.. is there another way i can pass my custom HttpMessageMeta through?

[dave]

hmm - that's trickier. And since ResponseMeta isn't currently open either... 😞

[dave]

the requestmeta is also handled inconsistently compared to the responses so think it will warrant further investigation.

[Tom Ellis]

rats!

[Tom Ellis]

for now i may cheat and pass the examples in a map to my custom renderer, and use the defintion id as a key to the example object

[dave]

temporarily, you could redefine ResponseMeta to be open locally - that will allow you to at least test your schema generation (which I suspect will be the meatiest piece of this)? The rest is going to need a rejiggle..

[Tom Ellis]

or that

[Tom Ellis]

🙂

[dave]

@Tom Ellis I think I’ve managed to crack the problem. Have generified the route dsl code to use the HttpMessageMeta<X> instead of the sub types. So I think you should be good to implement your own now.

[dave]

Releasing now in 3.130.0

[dave]

Let us know how it goes and if you do anything you can feed back in to the lib that would be great. 🙃

[Tom Ellis]

just btw - this worked great! thanks mate