Update documentation

api-guide/relations/index.html

@@ -414,6 +414,10 @@
                     </li>
                   
                     <li>
+                      <a href="#customizing-the-html-display">Customizing the HTML display</a>
+                    </li>
+                  
+                    <li>
                       <a href="#reverse-relations">Reverse relations</a>
                     </li>
                   
@@ -806,6 +810,13 @@ class CustomerHyperlink(serializers.HyperlinkedRelatedField):
 <p>In version 2.x a serializer class could <em>sometimes</em> automatically determine the <code>queryset</code> argument <em>if</em> a <code>ModelSerializer</code> class was being used.</p>
 <p>This behavior is now replaced with <em>always</em> using an explicit <code>queryset</code> argument for writable relational fields.</p>
 <p>Doing so reduces the amount of hidden 'magic' that <code>ModelSerializer</code> provides, makes the behavior of the field more clear, and ensures that it is trivial to move between using the <code>ModelSerializer</code> shortcut, or using fully explicit <code>Serializer</code> classes.</p>
+<h2 id="customizing-the-html-display">Customizing the HTML display</h2>
+<p>The built-in <code>__str__</code> method of the model will be used to generate string representations of the objects used to populate the <code>choices</code> property. These choices are used to populate select HTML inputs in the browsable API.</p>
+<p>To provide customized representations for such inputs, override <code>display_value()</code> of a <code>RelatedField</code> subclass. This method will receive a model object, and should return a string suitable for representing it. For example:</p>
+<pre><code>class TrackPrimaryKeyRelatedField(serializers.PrimaryKeyRelatedField):
+    def display_value(self, instance):
+        return 'Track: %s' % (instance.title)
+</code></pre>
 <h2 id="reverse-relations">Reverse relations</h2>
 <p>Note that reverse relationships are not automatically included by the <code>ModelSerializer</code> and <code>HyperlinkedModelSerializer</code> classes.  To include a reverse relationship, you must explicitly add it to the fields list.  For example:</p>
 <pre><code>class AlbumSerializer(serializers.ModelSerializer):

api-guide/requests/index.html

@@ -352,14 +352,6 @@
                     </li>
                   
                     <li>
-                      <a href="#data-and-files">.DATA and .FILES</a>
-                    </li>
-                  
-                    <li>
-                      <a href="#query_params_1">.QUERY_PARAMS</a>
-                    </li>
-                  
-                    <li>
                       <a href="#parsers">.parsers</a>
                     </li>
                   
@@ -457,10 +449,6 @@
 <h2 id="query_params">.query_params</h2>
 <p><code>request.query_params</code> is a more correctly named synonym for <code>request.GET</code>.</p>
 <p>For clarity inside your code, we recommend using <code>request.query_params</code> instead of the Django's standard <code>request.GET</code>. Doing so will help keep your codebase more correct and obvious - any HTTP method type may include query parameters, not just <code>GET</code> requests.</p>
-<h2 id="data-and-files">.DATA and .FILES</h2>
-<p>The old-style version 2.x <code>request.DATA</code> and <code>request.FILES</code> attributes are still available, but are now pending deprecation in favor of the unified <code>request.data</code> attribute.</p>
-<h2 id="query_params_1">.QUERY_PARAMS</h2>
-<p>The old-style version 2.x <code>request.QUERY_PARAMS</code> attribute is still available, but is now pending deprecation in favor of the more pythonic <code>request.query_params</code>.</p>
 <h2 id="parsers">.parsers</h2>
 <p>The <code>APIView</code> class or <code>@api_view</code> decorator will ensure that this property is automatically set to a list of <code>Parser</code> instances, based on the <code>parser_classes</code> set on the view or based on the <code>DEFAULT_PARSER_CLASSES</code> setting.</p>
 <p>You won't typically need to access this property.</p>

topics/3.2-announcement/index.html

@@ -398,7 +398,6 @@
 <p>There are no new deprecations in 3.2, although a number of existing deprecations have now escalated in line with our deprecation policy.</p>
 <ul>
 <li><code>request.DATA</code> was put on the deprecation path in 3.0. It has now been removed and its usage will result in an error. Use the more pythonic style of <code>request.data</code> instead.</li>
-<li><code>request.FILES</code> was put on the deprecation path in 3.0. It has now been removed and its usage will result in an error. Use the more pythonic style of <code>request.files</code> instead.</li>
 <li><code>request.QUERY_PARAMS</code> was put on the deprecation path in 3.0. It has now been removed and its usage will result in an error. Use the more pythonic style of <code>request.query_params</code> instead.</li>
 <li>The following <code>ModelSerializer.Meta</code> options have now been removed: <code>write_only_fields</code>, <code>view_name</code>, <code>lookup_field</code>. Use the more general <code>extra_kwargs</code> option instead.</li>
 </ul>