diff options
Diffstat (limited to 'docs/api-guide/generic-views.md')
| -rwxr-xr-x | docs/api-guide/generic-views.md | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md index e9efe709..b1c4e65a 100755 --- a/docs/api-guide/generic-views.md +++ b/docs/api-guide/generic-views.md @@ -49,7 +49,7 @@ For more complex cases you might also want to override various methods on the vi serializer = UserSerializer(queryset, many=True) return Response(serializer.data) -For very simple cases you might want to pass through any class attributes using the `.as_view()` method. For example, your URLconf might include something the following entry. +For very simple cases you might want to pass through any class attributes using the `.as_view()` method. For example, your URLconf might include something like the following entry: url(r'^/users/', ListCreateAPIView.as_view(model=User), name='user-list') @@ -74,10 +74,6 @@ The following attributes control the basic view behavior. * `lookup_field` - The model field that should be used to for performing object lookup of individual model instances. Defaults to `'pk'`. Note that when using hyperlinked APIs you'll need to ensure that *both* the API views *and* the serializer classes set the lookup fields if you need to use a custom value. * `lookup_url_kwarg` - The URL keyword argument that should be used for object lookup. The URL conf should include a keyword argument corresponding to this value. If unset this defaults to using the same value as `lookup_field`. -**Shortcuts**: - -* `model` - This shortcut may be used instead of setting either (or both) of the `queryset`/`serializer_class` attributes, although using the explicit style is generally preferred. If used instead of `serializer_class`, then `DEFAULT_MODEL_SERIALIZER_CLASS` setting will determine the base serializer class. Note that `model` is only ever used for generating a default queryset or serializer class - the `queryset` and `serializer_class` attributes are always preferred if provided. - **Pagination**: The following attributes are used to control pagination when used with list views. @@ -91,6 +87,10 @@ The following attributes are used to control pagination when used with list view * `filter_backends` - A list of filter backend classes that should be used for filtering the queryset. Defaults to the same value as the `DEFAULT_FILTER_BACKENDS` setting. +**Deprecated attributes**: + +* `model` - This shortcut may be used instead of setting either (or both) of the `queryset`/`serializer_class` attributes. The explicit style is preferred over the `.model` shortcut, and usage of this attribute is now deprecated. + ### Methods **Base methods**: @@ -101,7 +101,7 @@ Returns the queryset that should be used for list views, and that should be used This method should always be used rather than accessing `self.queryset` directly, as `self.queryset` gets evaluated only once, and those results are cached for all subsequent requests. -May be overridden to provide dynamic behavior such as returning a queryset that is specific to the user making the request. +May be overridden to provide dynamic behavior, such as returning a queryset, that is specific to the user making the request. For example: @@ -113,7 +113,7 @@ For example: Returns an object instance that should be used for detail views. Defaults to using the `lookup_field` parameter to filter the base queryset. -May be overridden to provide more complex behavior such as object lookups based on more than one URL kwarg. +May be overridden to provide more complex behavior, such as object lookups based on more than one URL kwarg. For example: @@ -133,7 +133,7 @@ Note that if your API doesn't include any object level permissions, you may opti Returns the classes that should be used to filter the queryset. Defaults to returning the `filter_backends` attribute. -May be override to provide more complex behavior with filters, as using different (or even exlusive) lists of filter_backends depending on different criteria. +May be overridden to provide more complex behavior with filters, such as using different (or even exlusive) lists of filter_backends depending on different criteria. For example: @@ -149,7 +149,7 @@ For example: Returns the class that should be used for the serializer. Defaults to returning the `serializer_class` attribute, or dynamically generating a serializer class if the `model` shortcut is being used. -May be override to provide dynamic behavior such as using different serializers for read and write operations, or providing different serializers to different types of users. +May be overridden to provide dynamic behavior, such as using different serializers for read and write operations, or providing different serializers to different types of users. For example: @@ -162,7 +162,7 @@ For example: Returns the page size to use with pagination. By default this uses the `paginate_by` attribute, and may be overridden by the client if the `paginate_by_param` attribute is set. -You may want to override this method to provide more complex behavior such as modifying page sizes based on the media type of the response. +You may want to override this method to provide more complex behavior, such as modifying page sizes based on the media type of the response. For example: @@ -204,7 +204,7 @@ You won't typically need to override the following methods, although you might n # Mixins -The mixin classes provide the actions that are used to provide the basic view behavior. Note that the mixin classes provide action methods rather than defining the handler methods such as `.get()` and `.post()` directly. This allows for more flexible composition of behavior. +The mixin classes provide the actions that are used to provide the basic view behavior. Note that the mixin classes provide action methods rather than defining the handler methods, such as `.get()` and `.post()`, directly. This allows for more flexible composition of behavior. ## ListModelMixin |