Abstracting/generalizing several classes
Many of the classes (permissions, mixins, etc.) in the superevents API follow a general pattern of 1. Abstract customized version of a DRF class 2. Class-specific, customized version of #1 3. (optional) Implemented, class-specific version of #2 We want all classes in #1 to either be in the root api directory or the root versioned (api.v*) directory. #2 and #3 classes should be in api.v*.superevents. This commit just moves some of the classes in #1 and #2 around so that they can eventually be used in the events API.
Showing
- gracedb/api/tests/__init__.py 0 additions, 0 deletionsgracedb/api/tests/__init__.py
- gracedb/api/tests/utils.py 2 additions, 1 deletiongracedb/api/tests/utils.py
- gracedb/api/v1/filters.py 34 additions, 0 deletionsgracedb/api/v1/filters.py
- gracedb/api/v1/mixins.py 4 additions, 3 deletionsgracedb/api/v1/mixins.py
- gracedb/api/v1/paginators.py 97 additions, 0 deletionsgracedb/api/v1/paginators.py
- gracedb/api/v1/permissions.py 136 additions, 0 deletionsgracedb/api/v1/permissions.py
- gracedb/api/v1/superevents/filters.py 0 additions, 28 deletionsgracedb/api/v1/superevents/filters.py
- gracedb/api/v1/superevents/paginators.py 0 additions, 54 deletionsgracedb/api/v1/superevents/paginators.py
- gracedb/api/v1/superevents/permissions.py 3 additions, 128 deletionsgracedb/api/v1/superevents/permissions.py
- gracedb/api/v1/superevents/serializers.py 2 additions, 2 deletionsgracedb/api/v1/superevents/serializers.py
- gracedb/api/v1/superevents/tests/test_access.py 2 additions, 1 deletiongracedb/api/v1/superevents/tests/test_access.py
- gracedb/api/v1/superevents/views.py 7 additions, 6 deletionsgracedb/api/v1/superevents/views.py
- gracedb/api/v1/superevents/viewsets.py 30 additions, 0 deletionsgracedb/api/v1/superevents/viewsets.py
- gracedb/api/v1/viewsets.py 0 additions, 25 deletionsgracedb/api/v1/viewsets.py
Loading
Please register or sign in to comment