From ccb2b8ff691760e4e93f3905975b285cee8b67f8 Mon Sep 17 00:00:00 2001 From: Xavier Ordoquy Date: Tue, 10 Feb 2015 23:56:05 +0100 Subject: Update documentation --- api-guide/fields/index.html | 6 ++++++ api-guide/filtering/index.html | 4 ++-- api-guide/generic-views/index.html | 8 ++------ api-guide/parsers/index.html | 2 +- api-guide/routers/index.html | 4 ++-- api-guide/viewsets/index.html | 2 +- topics/3.0-announcement/index.html | 4 ++-- topics/release-notes/index.html | 15 ++++++++++++++- topics/third-party-resources/index.html | 2 +- tutorial/1-serialization/index.html | 2 +- tutorial/2-requests-and-responses/index.html | 2 +- tutorial/5-relationships-and-hyperlinked-apis/index.html | 2 +- 12 files changed, 34 insertions(+), 19 deletions(-) diff --git a/api-guide/fields/index.html b/api-guide/fields/index.html index 83affe26..9fd73553 100644 --- a/api-guide/fields/index.html +++ b/api-guide/fields/index.html @@ -553,6 +553,10 @@ DRF Extra Fields +
The drf-compound-fields package provides "compound" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the many=True option. Also provided are fields for typed dictionaries and values that can be either a specific type or a list of items of that type.
The drf-extra-fields package provides extra serializer fields for REST framework, including Base64ImageField and PointField classes.
the djangorestframework-recursive package provides a RecursiveField for serializing and deserializing recursive structures
The django-rest-framework-gis package provides geographic addons for django rest framework like a  GeometryField field and a GeoJSON serializer.
The ordering attribute may be either a string or a list/tuple of strings.
The DjangoObjectPermissionsFilter is intended to be used together with the django-guardian package, with custom 'view' permissions added.  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.
The DjangoObjectPermissionsFilter is intended to be used together with the django-guardian package, with custom 'view' permissions added.  The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.
This filter class must be used with views that provide either a queryset or a model attribute.
If you're using DjangoObjectPermissionsFilter, you'll probably also want to add an appropriate object permissions class, to ensure that users can only operate on instances if they have the appropriate object permissions.  The easiest way to do this is to subclass DjangoObjectPermissions and add 'view' permissions to the perms_map attribute.
A complete example using both DjangoObjectPermissionsFilter and DjangoObjectPermissions might look something like this.
For more information on adding 'view' permissions for models, see the relevant section of the django-guardian documentation, and this blogpost.
For more information on adding 'view' permissions for models, see the relevant section of the django-guardian documentation, and this blogpost.
You can also provide your own generic filtering backend, or write an installable app for other developers to use.
diff --git a/api-guide/generic-views/index.html b/api-guide/generic-views/index.html index 675220d7..082f0bb0 100644 --- a/api-guide/generic-views/index.html +++ b/api-guide/generic-views/index.html @@ -577,14 +577,10 @@ class UserList(generics.ListCreateAPIView):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.Base methods:
get_queryset(self)Returns the queryset that should be used for list views, and that should be used as the base for lookups in detail views.  Defaults to returning the queryset specified by the queryset attribute, or the default queryset for the model if the model shortcut is being used.
Returns the queryset that should be used for list views, and that should be used as the base for lookups in detail views.  Defaults to returning the queryset specified by the queryset attribute.
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.
For example:
@@ -620,7 +616,7 @@ class UserList(generics.ListCreateAPIView): return (CategoryFilter,)get_serializer_class(self)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.
Returns the class that should be used for the serializer.  Defaults to returning the serializer_class attribute.
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:
def get_serializer_class(self):
diff --git a/api-guide/parsers/index.html b/api-guide/parsers/index.html
index 116b63da..e04f563e 100644
--- a/api-guide/parsers/index.html
+++ b/api-guide/parsers/index.html
@@ -543,7 +543,7 @@ def example_view(request, format=None):
     def put(self, request, filename, format=None):
         file_obj = request.data['file']
         # ...
-        # do some staff with uploaded file
+        # do some stuff with uploaded file
         # ...
         return Response(status=204)
 Optionally, you may also specify an additional argument:
base_name - The base to use for the URL names that are created.  If unset the basename will be automatically generated based on the model or queryset attribute on the viewset, if it has one.  Note that if the viewset does not include a model or queryset attribute then you must set base_name when registering the viewset.base_name - The base to use for the URL names that are created.  If unset the basename will be automatically generated based on the queryset attribute of the viewset, if it has one.  Note that if the viewset does not include a queryset attribute then you must set base_name when registering the viewset.The example above would generate the following URL patterns:
^users/{pk}/change-password/$  Name: 'user-change-password'For more information see the viewset documentation on marking extra actions for routing.
+For more information see the viewset documentation on marking extra actions for routing.
This router includes routes for the standard set of list, create, retrieve, update, partial_update and destroy actions.  The viewset can also mark additional methods to be routed, using the @detail_route or @list_route decorators.
Note however that upon removal of the queryset property from your ViewSet, any associated router will be unable to derive the base_name of your Model automatically, and so you you will have to specify the base_name kwarg as part of your router registration.
Note however that upon removal of the queryset property from your ViewSet, any associated router will be unable to derive the base_name of your Model automatically, and so you will have to specify the base_name kwarg as part of your router registration.
Also note that although this class provides the complete set of create/list/retrieve/update/destroy actions by default, you can restrict the available operations by using the standard permission classes.
The ReadOnlyModelViewSet class also inherits from GenericAPIView.  As with ModelViewSet it also includes implementations for various actions, but unlike ModelViewSet only provides the 'read-only' actions, .list() and .retrieve().
However this code would not be valid in 2.4.3:
However this code would not be valid in 3.0:
# Missing `queryset`
 class AccountSerializer(serializers.Serializer):
     organizations = serializers.SlugRelatedField(slug_field='name')
@@ -1051,7 +1051,7 @@ class OrganizationSerializer(serializers.Serializer):
 The style keyword argument can be used to pass through additional information from a serializer field, to the renderer class. In particular, the HTMLFormRenderer uses the base_template key to determine which template to render the field with.
 For example, to use a textarea control instead of the default input control, you would use the following…
 additional_notes = serializers.CharField(
-    style={'base_template': 'text_area.html'}
+    style={'base_template': 'textarea.html'}
 )
 
 Similarly, to use a radio button control instead of the default select control, you would use the following…
diff --git a/topics/release-notes/index.html b/topics/release-notes/index.html
index 477407fb..2d66b25f 100644
--- a/topics/release-notes/index.html
+++ b/topics/release-notes/index.html
@@ -439,6 +439,18 @@
 Date: 10th February 2015.
+_closable_objects breaks pickling. (#1850, #2492)User models with Throttling. (#2524)User.db_table in TokenAuthentication migration. (#2479)AttributeError tracebacks on Request objects. (#2530, #2108)ManyRelatedField.get_value clearing field on partial update. (#2475)detail_route and list_route mutable argument. (#2518)TokenAuthentication. (#2519)Date: 28th January 2015.
-
+ + diff --git a/topics/third-party-resources/index.html b/topics/third-party-resources/index.html index 0f9e1a9c..c3ad6d8d 100644 --- a/topics/third-party-resources/index.html +++ b/topics/third-party-resources/index.html @@ -561,7 +561,7 @@ You probably want to also tag the version now:This should all feel very familiar - it is not a lot different from working with regular Django views.
Notice that we're no longer explicitly tying our requests or responses to a given content type.  request.data can handle incoming json requests, but it can also handle yaml and other formats.  Similarly we're returning response objects with data, but allowing REST framework to render the response into the correct content type for us.
To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as http://example.com/api/items/4.json.
+To take advantage of the fact that our responses are no longer hardwired to a single content type let's add support for format suffixes to our API endpoints. Using format suffixes gives us URLs that explicitly refer to a given format, and means our API will be able to handle URLs such as http://example.com/api/items/4/.json.
Start by adding a format keyword argument to both of the views, like so.
def snippet_list(request, format=None):
 The list views for users and code snippets could end up returning quite a lot of instances, so really we'd like to make sure we paginate the results, and allow the API client to step through each of the individual pages.
-We can change the default list style to use pagination, by modifying our settings.py file slightly.  Add the following setting:
We can change the default list style to use pagination, by modifying our tutorial/settings.py file slightly.  Add the following setting:
REST_FRAMEWORK = {
     'PAGINATE_BY': 10
 }
-- 
cgit v1.2.3