Update documentation

3 files changed, 3 insertions, 3 deletions

diff --git a/tutorial/1-serialization/index.html b/tutorial/1-serialization/index.html
index 6782a94c..b9aae2a0 100644
--- a/tutorial/1-serialization/index.html
+++ b/tutorial/1-serialization/index.html
@@ -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')
diff --git a/tutorial/2-requests-and-responses/index.html b/tutorial/2-requests-and-responses/index.html
index 0f4980a7..cbc9c596 100644
--- a/tutorial/2-requests-and-responses/index.html
+++ b/tutorial/2-requests-and-responses/index.html
@@ -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>
diff --git a/tutorial/5-relationships-and-hyperlinked-apis/index.html b/tutorial/5-relationships-and-hyperlinked-apis/index.html
index 39b8dd42..488bcb4a 100644
--- a/tutorial/5-relationships-and-hyperlinked-apis/index.html
+++ b/tutorial/5-relationships-and-hyperlinked-apis/index.html
@@ -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
 }