Skip to content

fix: text to speech doc show request body #2036

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.

Sign up for GitHub

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

Merged
liuruibin merged 1 commit into from
Jan 20, 2025
+28 −0
Merged

fix: text to speech doc show request body #2036

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions apps/application/swagger_api/application_api.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -401,3 +401,25 @@ def get_request_params_api():
description=_('Application ID')),

]

class TextToSpeech(ApiMixin):
@staticmethod
def get_request_params_api():
return [openapi.Parameter(name='application_id',
in_=openapi.IN_PATH,
type=openapi.TYPE_STRING,
required=True,
description=_('Application ID')),

]

@staticmethod
def get_request_body_api():
return openapi.Schema(
type=openapi.TYPE_OBJECT,
required=[],
properties={
'text': openapi.Schema(type=openapi.TYPE_STRING, title=_("Text"),
description=_("Text")),
}
)
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your updated code for the get_request_params_api() function within TextToSpeech, there are a few minor adjustments and clarifications that can be made:

  1. Remove @staticmethod Decorator: Since you have defined both static methods (get_request_params_api() and get_request_body_api()) for the TextToSpeech class, it's redundant to use both decorators on all these methods. You only need one decorator per method.

  2. Correct Parameter Names: In the get_request_params_api() function, the parameter names should not include underscores (e.g., 'text_to_speech'). Use hyphens instead if needed.

Here is the revised version of your code:

@@ -401,7 +401,7 @@ def get_request_params_api():
                                           description=_('Application ID'))
                 ]
         ],
-
+        (
             'application-id',
             openapi.IN_PATH,
             openapi.TYPE_STRING,
             True,
             _('Application ID')

These changes ensure that the Python syntax is correct without unnecessary repetition. Let me know if you need further modifications!

6 changes: 6 additions & 0 deletions apps/application/views/application_views.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -629,6 +629,12 @@ class TextToSpeech(APIView):
authentication_classes = [TokenAuth]

@action(methods=['POST'], detail=False)
@swagger_auto_schema(operation_summary=_("text to speech"),
operation_id=_("text to speech"),
manual_parameters=ApplicationApi.TextToSpeech.get_request_params_api(),
request_body=ApplicationApi.TextToSpeech.get_request_body_api(),
responses=result.get_default_response(),
tags=[_('Application')])
@has_permissions(
ViewPermission([RoleConstants.ADMIN, RoleConstants.USER, RoleConstants.APPLICATION_ACCESS_TOKEN],
[lambda r, keywords: Permission(group=Group.APPLICATION,
Copy link
Contributor Author

@shaohuzhang1 shaohuzhang1 Jan 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code snippet appears to be defining an API view endpoint specifically for text-to-speech functionality. Here's a brief analysis:

Potential Issues:

  1. Duplicated Code: The get_request_params_api and get_request_body_api methods seem to return the same result based on their parameters. This means there might be redundant logic if these functions' behavior depends only on input parameters.

  2. Action Summary and ID Documentation: Although you've set up Swagger documentation using swagger_auto_schema, the summaries and IDs (operation_summary and operation_id) are not fully utilized. Consider adding more descriptive content here if needed.

  3. Permissions Handling: The permission handling is specified with a lambda function that evaluates whether a user is part of the 'APPLICATION' group or has one of the roles. Ensure that this logic aligns with your application's security requirements.

  4. Tags Documentation: The docstring provides tags under which the API method will be categorized. However, it’s important to ensure these tags match those used elsewhere in your API documentation to maintain consistency.

  5. Response Object: While responses=result.get_default_response() seems correct, depending on how result.default_response is defined, it may need further validation to ensure it returns the expected type and structure.

  6. Class Methods: There isn't any specific issue with the class methods themselves but ensuring they adhere to best practices (e.g., appropriate use of static/instance methods) would be good to consider.

  7. API Naming Conventions: Ensure that the API endpoints follow proper naming conventions and are consistent across similar endpoints.

Overall, the code looks structured correctly based on its purpose and intent. If you have additional requirements or constraints, adjusting these parts accordingly might be beneficial.

Expand Down
Loading