You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using a library with hundreds of auto-generated structs. All json-serializable with serde. However, the library does not implement the necessary traits for poem-openapi.
The rather tedious solution is to create a tandem pair for the structs I want to serialize via the poem library. But seeing as I would need to manually recreate hundreds of near-identical structs from a library... This can be done, but is tedious and error-prone. I would much rather link to the actual struct I am trying to use instead writing conversion functions back and fourth between the two.
So, my current thought is to use a bit of a proxy object? Something like the following:
Note that the above does not compile. And secondary to that, poem, to the best of my knowledge, does not really use serde. So attempting to use #[serde(flatten)] would likely be a useless gesture. The idea to use concreate have a named reference to each proxy reference. I got this idea while looking though the issues. Specifically this issue that references this practice. Where the issue focused on allowing named generics. If I could do something like this, where I can easily name each concrete type for the proxy, that would be a much easier method to include structs maintained by another library if no other method is currently present to do the same.
The text was updated successfully, but these errors were encountered:
I am using a library with hundreds of auto-generated structs. All json-serializable with
serde
. However, the library does not implement the necessary traits for poem-openapi.The rather tedious solution is to create a tandem pair for the structs I want to serialize via the poem library. But seeing as I would need to manually recreate hundreds of near-identical structs from a library... This can be done, but is tedious and error-prone. I would much rather link to the actual struct I am trying to use instead writing conversion functions back and fourth between the two.
So, my current thought is to use a bit of a proxy object? Something like the following:
Note that the above does not compile. And secondary to that, poem, to the best of my knowledge, does not really use
serde
. So attempting to use#[serde(flatten)]
would likely be a useless gesture. The idea to useconcreate
have a named reference to each proxy reference. I got this idea while looking though the issues. Specifically this issue that references this practice. Where the issue focused on allowing named generics. If I could do something like this, where I can easily name each concrete type for the proxy, that would be a much easier method to include structs maintained by another library if no other method is currently present to do the same.The text was updated successfully, but these errors were encountered: