Update documentation

This commit is contained in:
Xavier Ordoquy 2015-02-10 23:56:05 +01:00
parent b0a1712ebd
commit ccb2b8ff69
12 changed files with 34 additions and 19 deletions

View File

@ -553,6 +553,10 @@
<a href="#drf-extra-fields">DRF Extra Fields</a>
</li>
<li>
<a href="#djangrestframework-recursive">djangrestframework-recursive</a>
</li>
<li>
<a href="#django-rest-framework-gis">django-rest-framework-gis</a>
</li>
@ -978,6 +982,8 @@ def to_internal_value(self, data):
<p>The <a href="http://drf-compound-fields.readthedocs.org">drf-compound-fields</a> package provides "compound" serializer fields, such as lists of simple values, which can be described by other fields rather than serializers with the <code>many=True</code> 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.</p>
<h2 id="drf-extra-fields">DRF Extra Fields</h2>
<p>The <a href="https://github.com/Hipo/drf-extra-fields">drf-extra-fields</a> package provides extra serializer fields for REST framework, including <code>Base64ImageField</code> and <code>PointField</code> classes.</p>
<h2 id="djangrestframework-recursive">djangrestframework-recursive</h2>
<p>the <a href="https://github.com/heywbj/django-rest-framework-recursive">djangorestframework-recursive</a> package provides a <code>RecursiveField</code> for serializing and deserializing recursive structures</p>
<h2 id="django-rest-framework-gis">django-rest-framework-gis</h2>
<p>The <a href="https://github.com/djangonauts/django-rest-framework-gis">django-rest-framework-gis</a> package provides geographic addons for django rest framework like a <code>GeometryField</code> field and a GeoJSON serializer.</p>
<h2 id="django-rest-framework-hstore">django-rest-framework-hstore</h2>

View File

@ -708,7 +708,7 @@ class ProductFilter(django_filters.FilterSet):
<p>The <code>ordering</code> attribute may be either a string or a list/tuple of strings.</p>
<hr />
<h2 id="djangoobjectpermissionsfilter">DjangoObjectPermissionsFilter</h2>
<p>The <code>DjangoObjectPermissionsFilter</code> is intended to be used together with the <a href="http://pythonhosted.org/django-guardian/"><code>django-guardian</code></a> package, with custom <code>'view'</code> permissions added. The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.</p>
<p>The <code>DjangoObjectPermissionsFilter</code> is intended to be used together with the <a href="https://django-guardian.readthedocs.org/"><code>django-guardian</code></a> package, with custom <code>'view'</code> permissions added. The filter will ensure that querysets only returns objects for which the user has the appropriate view permission.</p>
<p>This filter class must be used with views that provide either a <code>queryset</code> or a <code>model</code> attribute.</p>
<p>If you're using <code>DjangoObjectPermissionsFilter</code>, 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 <code>DjangoObjectPermissions</code> and add <code>'view'</code> permissions to the <code>perms_map</code> attribute.</p>
<p>A complete example using both <code>DjangoObjectPermissionsFilter</code> and <code>DjangoObjectPermissions</code> might look something like this.</p>
@ -739,7 +739,7 @@ class ProductFilter(django_filters.FilterSet):
filter_backends = (filters.DjangoObjectPermissionsFilter,)
permission_classes = (myapp.permissions.CustomObjectPermissions,)
</code></pre>
<p>For more information on adding <code>'view'</code> permissions for models, see the <a href="http://pythonhosted.org/django-guardian/userguide/assign.html">relevant section</a> of the <code>django-guardian</code> documentation, and <a href="http://blog.nyaruka.com/adding-a-view-permission-to-django-models">this blogpost</a>.</p>
<p>For more information on adding <code>'view'</code> permissions for models, see the <a href="https://django-guardian.readthedocs.org/en/latest/userguide/assign.html">relevant section</a> of the <code>django-guardian</code> documentation, and <a href="http://blog.nyaruka.com/adding-a-view-permission-to-django-models">this blogpost</a>.</p>
<hr />
<h1 id="custom-generic-filtering">Custom generic filtering</h1>
<p>You can also provide your own generic filtering backend, or write an installable app for other developers to use.</p>

View File

@ -577,14 +577,10 @@ class UserList(generics.ListCreateAPIView):
<ul>
<li><code>filter_backends</code> - A list of filter backend classes that should be used for filtering the queryset. Defaults to the same value as the <code>DEFAULT_FILTER_BACKENDS</code> setting.</li>
</ul>
<p><strong>Deprecated attributes</strong>:</p>
<ul>
<li><code>model</code> - This shortcut may be used instead of setting either (or both) of the <code>queryset</code>/<code>serializer_class</code> attributes. The explicit style is preferred over the <code>.model</code> shortcut, and usage of this attribute is now deprecated.</li>
</ul>
<h3 id="methods">Methods</h3>
<p><strong>Base methods</strong>:</p>
<h4 id="get_querysetself"><code>get_queryset(self)</code></h4>
<p>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 <code>queryset</code> attribute, or the default queryset for the model if the <code>model</code> shortcut is being used.</p>
<p>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 <code>queryset</code> attribute.</p>
<p>This method should always be used rather than accessing <code>self.queryset</code> directly, as <code>self.queryset</code> gets evaluated only once, and those results are cached for all subsequent requests.</p>
<p>May be overridden to provide dynamic behavior, such as returning a queryset, that is specific to the user making the request.</p>
<p>For example:</p>
@ -620,7 +616,7 @@ class UserList(generics.ListCreateAPIView):
return (CategoryFilter,)
</code></pre>
<h4 id="get_serializer_classself"><code>get_serializer_class(self)</code></h4>
<p>Returns the class that should be used for the serializer. Defaults to returning the <code>serializer_class</code> attribute, or dynamically generating a serializer class if the <code>model</code> shortcut is being used.</p>
<p>Returns the class that should be used for the serializer. Defaults to returning the <code>serializer_class</code> attribute.</p>
<p>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.</p>
<p>For example:</p>
<pre><code>def get_serializer_class(self):

View File

@ -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)
</code></pre>

View File

@ -459,7 +459,7 @@ urlpatterns = router.urls
</ul>
<p>Optionally, you may also specify an additional argument:</p>
<ul>
<li><code>base_name</code> - The base to use for the URL names that are created. If unset the basename will be automatically generated based on the <code>model</code> or <code>queryset</code> attribute on the viewset, if it has one. Note that if the viewset does not include a <code>model</code> or <code>queryset</code> attribute then you must set <code>base_name</code> when registering the viewset.</li>
<li><code>base_name</code> - The base to use for the URL names that are created. If unset the basename will be automatically generated based on the <code>queryset</code> attribute of the viewset, if it has one. Note that if the viewset does not include a <code>queryset</code> attribute then you must set <code>base_name</code> when registering the viewset.</li>
</ul>
<p>The example above would generate the following URL patterns:</p>
<ul>
@ -534,7 +534,7 @@ class UserViewSet(ModelViewSet):
<ul>
<li>URL pattern: <code>^users/{pk}/change-password/$</code> Name: <code>'user-change-password'</code></li>
</ul>
<p>For more information see the viewset documentation on <a href="../../viewsets.html#marking-extra-actions-for-routing">marking extra actions for routing</a>.</p>
<p>For more information see the viewset documentation on <a href="../viewsets#marking-extra-actions-for-routing">marking extra actions for routing</a>.</p>
<h1 id="api-guide">API Guide</h1>
<h2 id="simplerouter">SimpleRouter</h2>
<p>This router includes routes for the standard set of <code>list</code>, <code>create</code>, <code>retrieve</code>, <code>update</code>, <code>partial_update</code> and <code>destroy</code> actions. The viewset can also mark additional methods to be routed, using the <code>@detail_route</code> or <code>@list_route</code> decorators.</p>

View File

@ -587,7 +587,7 @@ class UserViewSet(viewsets.ModelViewSet):
def get_queryset(self):
return self.request.user.accounts.all()
</code></pre>
<p>Note however that upon removal of the <code>queryset</code> property from your <code>ViewSet</code>, any associated <a href="../routers">router</a> will be unable to derive the base_name of your Model automatically, and so you you will have to specify the <code>base_name</code> kwarg as part of your <a href="../routers">router registration</a>.</p>
<p>Note however that upon removal of the <code>queryset</code> property from your <code>ViewSet</code>, any associated <a href="../routers">router</a> will be unable to derive the base_name of your Model automatically, and so you will have to specify the <code>base_name</code> kwarg as part of your <a href="../routers">router registration</a>.</p>
<p>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.</p>
<h2 id="readonlymodelviewset">ReadOnlyModelViewSet</h2>
<p>The <code>ReadOnlyModelViewSet</code> class also inherits from <code>GenericAPIView</code>. As with <code>ModelViewSet</code> it also includes implementations for various actions, but unlike <code>ModelViewSet</code> only provides the 'read-only' actions, <code>.list()</code> and <code>.retrieve()</code>.</p>

View File

@ -936,7 +936,7 @@ def to_representation(self, value):
class Meta:
model = Account
</code></pre>
<p>However this code <em>would not be valid</em> in <code>2.4.3</code>:</p>
<p>However this code <em>would not be valid</em> in <code>3.0</code>:</p>
<pre><code># Missing `queryset`
class AccountSerializer(serializers.Serializer):
organizations = serializers.SlugRelatedField(slug_field='name')
@ -1051,7 +1051,7 @@ class OrganizationSerializer(serializers.Serializer):
<p>The <code>style</code> keyword argument can be used to pass through additional information from a serializer field, to the renderer class. In particular, the <code>HTMLFormRenderer</code> uses the <code>base_template</code> key to determine which template to render the field with.</p>
<p>For example, to use a <code>textarea</code> control instead of the default <code>input</code> control, you would use the following…</p>
<pre><code>additional_notes = serializers.CharField(
style={'base_template': 'text_area.html'}
style={'base_template': 'textarea.html'}
)
</code></pre>
<p>Similarly, to use a radio button control instead of the default <code>select</code> control, you would use the following…</p>

View File

@ -439,6 +439,18 @@
</code></pre>
<hr />
<h2 id="30x-series">3.0.x series</h2>
<h3 id="305">3.0.5</h3>
<p><strong>Date</strong>: <a href="https://github.com/tomchristie/django-rest-framework/issues?q=milestone%3A%223.0.5+Release%22">10th February 2015</a>.</p>
<ul>
<li>Fix a bug where <code>_closable_objects</code> breaks pickling. (<a href="https://github.com/tomchristie/django-rest-framework/issues/1850">#1850</a>, <a href="https://github.com/tomchristie/django-rest-framework/issues/2492">#2492</a>)</li>
<li>Allow non-standard <code>User</code> models with <code>Throttling</code>. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2524">#2524</a>)</li>
<li>Support custom <code>User.db_table</code> in TokenAuthentication migration. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2479">#2479</a>)</li>
<li>Fix misleading <code>AttributeError</code> tracebacks on <code>Request</code> objects. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2530">#2530</a>, <a href="https://github.com/tomchristie/django-rest-framework/issues/2108">#2108</a>)</li>
<li><code>ManyRelatedField.get_value</code> clearing field on partial update. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2475">#2475</a>)</li>
<li>Removed '.model' shortcut from code. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2486">#2486</a>)</li>
<li>Fix <code>detail_route</code> and <code>list_route</code> mutable argument. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2518">#2518</a>)</li>
<li>Prefetching the user object when getting the token in <code>TokenAuthentication</code>. (<a href="https://github.com/tomchristie/django-rest-framework/issues/2519">#2519</a>)</li>
</ul>
<h3 id="304">3.0.4</h3>
<p><strong>Date</strong>: <a href="https://github.com/tomchristie/django-rest-framework/issues?q=milestone%3A%223.0.4+Release%22">28th January 2015</a>.</p>
<ul>
@ -1021,7 +1033,8 @@
<p><!-- 3.0.2 -->
<!-- 3.0.3 -->
<!-- 3.0.4 --></p>
<!-- 3.0.4 -->
<!-- 3.0.5 --></p>
</div>
<!--/span-->

View File

@ -561,7 +561,7 @@ You probably want to also tag the version now:
<li><a href="https://github.com/eofs/django-rest-framework-proxy">django-rest-framework-proxy</a> - Proxy to redirect incoming request to another API server.</li>
<li><a href="https://github.com/AppsFuel/gaiarestframework">gaiarestframework</a> - Utils for django-rest-framewok</li>
<li><a href="https://github.com/chibisov/drf-extensions">drf-extensions</a> - A collection of custom extensions</li>
<li><a href="https://github.com/toranb/ember-data-django-rest-adapter">ember-data-django-rest-adapter</a> - An ember-data adapter</li>
<li><a href="https://github.com/dustinfarris/ember-django-adapter">ember-django-adapter</a> - An adapter for working with Ember.js</li>
</ul>
<h2 id="other-resources">Other Resources</h2>
<h3 id="tutorials">Tutorials</h3>

View File

@ -487,7 +487,7 @@ from snippets.models import Snippet, LANGUAGE_CHOICES, STYLE_CHOICES
class SnippetSerializer(serializers.Serializer):
pk = serializers.IntegerField(read_only=True)
title = serializers.CharField(required=False, allow_blank=True, max_length=100)
code = serializers.CharField(style={'type': 'textarea'})
code = serializers.CharField(style={'base_template': 'textarea.html'})
linenos = serializers.BooleanField(required=False)
language = serializers.ChoiceField(choices=LANGUAGE_CHOICES, default='python')
style = serializers.ChoiceField(choices=STYLE_CHOICES, default='friendly')

View File

@ -481,7 +481,7 @@ def snippet_detail(request, pk):
<p>This should all feel very familiar - it is not a lot different from working with regular Django views.</p>
<p>Notice that we're no longer explicitly tying our requests or responses to a given content type. <code>request.data</code> can handle incoming <code>json</code> requests, but it can also handle <code>yaml</code> 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.</p>
<h2 id="adding-optional-format-suffixes-to-our-urls">Adding optional format suffixes to our URLs</h2>
<p>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 <a href="http://example.com/api/items/4.json">http://example.com/api/items/4.json</a>.</p>
<p>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 <a href="http://example.com/api/items/4.json">http://example.com/api/items/4/.json</a>.</p>
<p>Start by adding a <code>format</code> keyword argument to both of the views, like so.</p>
<pre><code>def snippet_list(request, format=None):
</code></pre>

View File

@ -512,7 +512,7 @@ urlpatterns += [
</code></pre>
<h2 id="adding-pagination">Adding pagination</h2>
<p>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.</p>
<p>We can change the default list style to use pagination, by modifying our <code>settings.py</code> file slightly. Add the following setting:</p>
<p>We can change the default list style to use pagination, by modifying our <code>tutorial/settings.py</code> file slightly. Add the following setting:</p>
<pre><code>REST_FRAMEWORK = {
'PAGINATE_BY': 10
}