mirror of
https://github.com/encode/django-rest-framework.git
synced 2025-02-06 14:40:56 +03:00
Update documentation
This commit is contained in:
parent
78f5bcb5cb
commit
61eb64ed24
|
@ -943,6 +943,14 @@ AccountSerializer():
|
|||
read_only_fields = ('account_name',)
|
||||
</code></pre>
|
||||
<p>Model fields which have <code>editable=False</code> set, and <code>AutoField</code> fields will be set to read-only by default, and do not need to be added to the <code>read_only_fields</code> option.</p>
|
||||
<hr />
|
||||
<p><strong>Note</strong>: There is a special-case where a read-only field is part of a <code>unique_together</code> constraint at the model level. In this case the field is required by the serializer class in order to validate the constraint, but should also not be editable by the user.</p>
|
||||
<p>The right way to deal with this is to specify the field explicitly on the serializer, providing both the <code>read_only=True</code> and <code>default=…</code> keyword arguments.</p>
|
||||
<p>One example of this is a read-only relation to the currently authenticated <code>User</code> which is <code>unique_together</code> with another identifier. In this case you would declare the user field like so:</p>
|
||||
<pre><code>user = serializers.PrimaryKeyRelatedField(read_only=True, default=serializers.CurrentUserDefault())
|
||||
</code></pre>
|
||||
<p>Please review the <a href="../..//api-guide/validators/">Validators Documentation</a> for details on the <a href="../..//api-guide/validators/#uniquetogethervalidator">UniqueTogetherValidator</a> and <a href="../..//api-guide/validators/#currentuserdefault">CurrentUserDefault</a> classes.</p>
|
||||
<hr />
|
||||
<h2 id="specifying-additional-keyword-arguments-for-fields">Specifying additional keyword arguments for fields.</h2>
|
||||
<p>There is also a shortcut allowing you to specify arbitrary additional keyword arguments on fields, using the <code>extra_kwargs</code> option. Similarly to <code>read_only_fields</code> this means you do not need to explicitly declare the field on the serializer.</p>
|
||||
<p>This option is a dictionary, mapping field names to a dictionary of keyword arguments. For example:</p>
|
||||
|
@ -1057,7 +1065,7 @@ class BookSerializer(serializers.Serializer):
|
|||
<li>How do you determine which instance should be updated for each item in the list of data?</li>
|
||||
<li>How should insertions be handled? Are they invalid, or do they create new objects?</li>
|
||||
<li>How should removals be handled? Do they imply object deletion, or removing a relationship? Should they be silently ignored, or are they invalid?</li>
|
||||
<li>How should ordering be handled? Does changing the position of two items imply any state change or is it ignored? </li>
|
||||
<li>How should ordering be handled? Does changing the position of two items imply any state change or is it ignored?</li>
|
||||
</ul>
|
||||
<p>Here's an example of how you might choose to implement multiple updates:</p>
|
||||
<pre><code>class BookListSerializer(serializers.ListSerializer):
|
||||
|
|
|
@ -579,6 +579,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>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>
|
||||
|
|
|
@ -1122,6 +1122,7 @@ amount = serializers.DecimalField(
|
|||
<ul>
|
||||
<li>The serializer <code>ChoiceField</code> does not currently display nested choices, as was the case in 2.4. This will be address as part of 3.1.</li>
|
||||
<li>Due to the new templated form rendering, the 'widget' option is no longer valid. This means there's no easy way of using third party "autocomplete" widgets for rendering select inputs that contain a large number of choices. You'll either need to use a regular select or a plain text input. We may consider addressing this in 3.1 or 3.2 if there's sufficient demand.</li>
|
||||
<li>Some of the default validation error messages were rewritten and might no longer be pre-translated. You can still <a href="https://docs.djangoproject.com/en/dev/topics/i18n/translation/#localization-how-to-create-language-files">create language files with Django</a> if you wish to localize them.</li>
|
||||
</ul>
|
||||
<hr />
|
||||
<h2 id="whats-coming-next">What's coming next</h2>
|
||||
|
|
|
@ -361,6 +361,10 @@
|
|||
<a href="#upgrading">Upgrading</a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#30x-series">3.0.x series</a>
|
||||
</li>
|
||||
|
||||
<li>
|
||||
<a href="#24x-series">2.4.x series</a>
|
||||
</li>
|
||||
|
@ -426,6 +430,11 @@
|
|||
<pre><code>pip freeze | grep djangorestframework
|
||||
</code></pre>
|
||||
<hr />
|
||||
<h2 id="30x-series">3.0.x series</h2>
|
||||
<h3 id="300">3.0.0</h3>
|
||||
<p><strong>Date</strong>: 1st December 2014</p>
|
||||
<p>For full details see the <a href="../3.0-announcement">3.0 release announcement</a>.</p>
|
||||
<hr />
|
||||
<h2 id="24x-series">2.4.x series</h2>
|
||||
<h3 id="244">2.4.4</h3>
|
||||
<p><strong>Date</strong>: <a href="https://github.com/tomchristie/django-rest-framework/issues?q=milestone%3A%222.4.4+Release%22+">3rd November 2014</a>.</p>
|
||||
|
|
|
@ -435,7 +435,7 @@ from pygments import highlight
|
|||
</code></pre>
|
||||
<p>When that's all done we'll need to update our database tables.
|
||||
Normally we'd create a database migration in order to do that, but for the purposes of this tutorial, let's just delete the database and start again.</p>
|
||||
<pre><code>rm tmp.db
|
||||
<pre><code>rm -f tmp.db db.sqlite3
|
||||
rm -r snippets/migrations
|
||||
python manage.py makemigrations snippets
|
||||
python manage.py migrate
|
||||
|
@ -448,7 +448,7 @@ python manage.py migrate
|
|||
<pre><code>from django.contrib.auth.models import User
|
||||
|
||||
class UserSerializer(serializers.ModelSerializer):
|
||||
snippets = serializers.PrimaryKeyRelatedField(many=True)
|
||||
snippets = serializers.PrimaryKeyRelatedField(many=True, queryset=Snippet.objects.all())
|
||||
|
||||
class Meta:
|
||||
model = User
|
||||
|
|
|
@ -421,7 +421,7 @@ class SnippetHighlight(generics.GenericAPIView):
|
|||
</code></pre>
|
||||
<p>As usual we need to add the new views that we've created in to our URLconf.
|
||||
We'll add a url pattern for our new API root in <code>snippets/urls.py</code>:</p>
|
||||
<pre><code>url(r'^$', 'api_root'),
|
||||
<pre><code>url(r'^$', views.api_root),
|
||||
</code></pre>
|
||||
<p>And then add a url pattern for the snippet highlights:</p>
|
||||
<pre><code>url(r'^snippets/(?P<pk>[0-9]+)/highlight/$', views.SnippetHighlight.as_view()),
|
||||
|
|
Loading…
Reference in New Issue
Block a user