Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for externalizing strings in generated openapi schema via… #2418

Conversation

tkachenkoas
Copy link

Originates from #2401

Can you please hint, what files should be adjusted to publish documentation properly?

… properties that follow conventional naming similar to openapi schema.
@tkachenkoas
Copy link
Author

@bnasslahsen please take a look at this PR and let me know if something requires adjustment

@bnasslahsen
Copy link
Contributor

@tkachenkoas,

Thank you for your contribution. I believe it's not yet complete.

Do you think you can add the case of OpenAPI groups as well ?

@tkachenkoas
Copy link
Author

tkachenkoas commented Dec 15, 2023

@tkachenkoas,

Thank you for your contribution. I believe it's not yet complete.

Do you think you can add the case of OpenAPI groups as well ?

@bnasslahsen

By "not complete" you mean all fields in the Schema model (like min/max etc.). I didn't plan to add them in the first version, but if you think it makes sense - surely, I'll add it

What case and behavior do you mean by supporting groups?

E.g. sth like
springdoc.specification-strings.{group-name}.paths.{operationId}.description
should override "general" string
springdoc.specification-strings.paths.{operationId}.description

I guess yes, it makes sense when we have identical method names "like getAccount" in UI api and MOBILE api (and in global schema one of them will become getAccount_1)?..

@bnasslahsen
Copy link
Contributor

@tkachenkoas,

Sorry for my late response.
I confirm your properties description, is the exact expected result.

For the method names, more than 99% of cases they are unique per path and it can be considered for the first MVP.
Supporting polymorphism of exposed methods in controller, will bring more complexity and can be considered for another enhancment.

@tkachenkoas
Copy link
Author

@tkachenkoas,

Sorry for my late response. I confirm your properties description, is the exact expected result.

For the method names, more than 99% of cases they are unique per path and it can be considered for the first MVP. Supporting polymorphism of exposed methods in controller, will bring more complexity and can be considered for another enhancment.

ok, now it's my turn to respond with delay... :)

do I need to modify some other places for this functionality to appear in the documentation?

@bnasslahsen
Copy link
Contributor

@tkachenkoas,

It doesn't seem to me that the groups support is implemented.
if it's the case, can you add the the corresponding another test case using ?

springdoc.specification-strings.{group-name}.paths.{operationId}.description

@tkachenkoas
Copy link
Author

@tkachenkoas,

It doesn't seem to me that the groups support is implemented. if it's the case, can you add the the corresponding another test case using ?

springdoc.specification-strings.{group-name}.paths.{operationId}.description

ok, I guess I misunderstood one of the previous messages. Adjusted the logic and added a test-case

@bnasslahsen
Copy link
Contributor

@tkachenkoas,

Your push was too fast.
i will have to take care of it.

@bnasslahsen
Copy link
Contributor

bnasslahsen commented Feb 26, 2024

@tkachenkoas,

code merged:

  • Removed springdoc.api-docs.specification-string-properties property
  • Replaced springdoc.specification-strings by springdoc.open-api

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants