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
How to separate out schema to keep controllers clean and focused on business logic? #2231
Comments
Mir-Zairan
changed the title
How to separate out documentation files to keep controllers clean and focused on business logic?
How to separate out annotations to keep controllers clean and focused on business logic?
Mar 4, 2024
Mir-Zairan
changed the title
How to separate out annotations to keep controllers clean and focused on business logic?
How to separate out schema to keep controllers clean and focused on business logic?
Mar 5, 2024
You could try extending the
Or a PR would have to be made to support loading/appending the generated spec with some existing files through a configuration option. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
I've successfully documented various API endpoints, and while the documentation functions correctly, I find that the presence of API documentation annotations clutters my controllers, leading to dissatisfaction with their readability and structure.
I tried to move schema to the nelmio_api_doc.yaml config file and then used ref to reference a particular schema. Although that did work but it still cluttered the nelmio_api_doc.yaml config file which I don't want. I would rather like to keep schema in a separate yaml or xml file and then somehow use that for providing a schema within the controller using ref or something else.
Example:
Question:
Is there an alternative method to declutter the controllers by extracting these annotations, specifically the scheme part? I'm curious if it's possible to define these annotations in XML or YAML files and then integrate those files somehow to maintain the documentation separately.
Note:
Using @model is out of question!
The text was updated successfully, but these errors were encountered: