guardrail-dev
Question: Can I override name of generated case classes?
- Is it possible to override the names of the generated cases classes for my model types?
e.g. In the schema below a case class called Foo would be generated. Is it possible to change the to a different name without changing the Foo attribute. I'd like the entity to be called Foo in our docs, but FooApi internally in the code.
definitions:
Foo:
type: object
properties:
...
- Is there a Gitter/Slack room where questions such as this should be directed?
@eli-jordan As @kelnos said, no, this is not currently a supported feature.
That being said, if you've got a compelling enough reason for this to be implemented, we'd love to hear it! Implementing it shouldn't be overly difficult, the question at this point is not what could be implemented, but why should it be implemented. Striking a balance between features and practicality is the line we're trying to walk.
We don't have a gitter currently, so feel free to discuss here
Thanks @kelnos @blast-hardcheese
So the motivation for us is that we have multiple representations for similar domain objects. We have the ReST API representation, the internal domain objects, and the database representation. We would like to establish a naming convention where ApiFoo is the ReST API version Foo is the internal domain object and FooDto is the database representation. Currently the only way to achieve this is to name the definition in the swagger spec ApiFoo, however this means that our docs will have an entity called ApiFoo rather than Foo. I guess this is not a huge issue, but would be a nice to have :)
That definitely makes sense. I think this matches the intent of mapping, but for top-level objects. What do you propose for the user-facing features? Do you envision any additional settings, or is it just an x-jvm-... vendor extension?
Won't consumers of your docs be confused that way? If I see in the docs "Hey, use this Foo class", but then I don't find a Foo class but instead see an ApiFoo class, I'm sure I'll figure it out, but I'll a) be a little confused, and b) probably write to you and tell you that your API docs have an error.
@kelnos Well my API docs don't really say anything about classes. They talk about entities in a ReST API. The semantics of the code generator control what the classes are named. Though, I do see your point, that could be confusing.
@blast-hardcheese Perhaps something like
x-jvm-server-name and x-jvm-client-name so we could have ApiFoo on the server and Foo on the client.