Merge remote-tracking branch 'upstream/master' into writable-nested-modelserializer

5 files changed, 18 insertions, 13 deletions

diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md
index 20b9440b..cd1bc7a1 100755
--- a/docs/api-guide/generic-views.md
+++ b/docs/api-guide/generic-views.md
@@ -60,7 +60,7 @@ The following attributes control the basic view behavior.
 
 * `queryset` - The queryset that should be used for returning objects from this view.  Typically, you must either set this attribute, or override the `get_queryset()` method.
 * `serializer_class` - The serializer class that should be used for validating and deserializing input, and for serializing output.  Typically, you must either set this attribute, or override the `get_serializer_class()` method.
-* `lookup_field` - The field that should be used to lookup individual model instances.  Defaults to `'pk'`.  The URL conf should include a keyword argument corresponding to this value.  More complex lookup styles can be supported by overriding the `get_object()` method.
+* `lookup_field` - The field that should be used to lookup individual model instances.  Defaults to `'pk'`.  The URL conf should include a keyword argument corresponding to this value.  More complex lookup styles can be supported by overriding the `get_object()` method.  Note that when using hyperlinked APIs you'll need to ensure that *both* the API views *and* the serializer classes use lookup fields that correctly correspond with the URL conf.
 
 **Shortcuts**:
 
@@ -131,7 +131,7 @@ You may want to override this method to provide more complex behavior such as mo
 For example:
 
     def get_paginate_by(self):
-        self.request.accepted_renderer.format == 'html':
+        if self.request.accepted_renderer.format == 'html':
             return 20
         return 100
 
diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md
index 44ee7e39..4c02d530 100644
--- a/docs/api-guide/serializers.md
+++ b/docs/api-guide/serializers.md
@@ -39,7 +39,7 @@ Declaring a serializer looks very similar to declaring a form:
             an existing model instance, or create a new model instance.
             """
             if instance is not None:
-                instance.title = attrs.get('title', instance.title)
+                instance.email = attrs.get('email', instance.email)
                 instance.content = attrs.get('content', instance.content)
                 instance.created = attrs.get('created', instance.created)
                 return instance
@@ -387,7 +387,7 @@ There needs to be a way of determining which views should be used for hyperlinki
 
 By default hyperlinks are expected to correspond to a view name that matches the style `'{model_name}-detail'`, and looks up the instance by a `pk` keyword argument.
 
-You can change the field that is used for object lookups by setting the `lookup_field` option.  The value of this option should correspond both with a kwarg in the URL conf, and with an field on the model.  For example:
+You can change the field that is used for object lookups by setting the `lookup_field` option.  The value of this option should correspond both with a kwarg in the URL conf, and with a field on the model.  For example:
 
     class AccountSerializer(serializers.HyperlinkedModelSerializer):
         class Meta:
@@ -395,6 +395,8 @@ You can change the field that is used for object lookups by setting the `lookup_
             fields = ('url', 'account_name', 'users', 'created')
             lookup_field = 'slug'
 
+Not that the `lookup_field` will be used as the default on *all* hyperlinked fields, including both the URL identity, and any hyperlinked relationships.
+
 For more specfic requirements such as specifying a different lookup for each field, you'll want to set the fields on the serializer explicitly.  For example:
 
     class AccountSerializer(serializers.HyperlinkedModelSerializer):
diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md
index 2783da98..79257e2a 100644
--- a/docs/api-guide/viewsets.md
+++ b/docs/api-guide/viewsets.md
@@ -209,8 +209,6 @@ To create a base viewset class that provides `create`, `list` and `retrieve` ope
                                     mixins.ListMixin,
                                     mixins.RetrieveMixin,
                                     viewsets.GenericViewSet):
-        pass
-
         """
         A viewset that provides `retrieve`, `update`, and `list` actions.
         
diff --git a/docs/topics/credits.md b/docs/topics/credits.md
index bbe209c7..b4bd3561 100644
--- a/docs/topics/credits.md
+++ b/docs/topics/credits.md
@@ -139,6 +139,8 @@ The following people have helped make REST framework great.
 * Pascal Borreli - [pborreli]
 * Alex Burgel - [aburgel]
 * David Medina - [copitux]
+* Areski Belaid - [areski]
+* Ethan Freman - [mindlace]
 
 Many thanks to everyone who's contributed to the project.
 
@@ -314,3 +316,5 @@ You can also contact [@_tomchristie][twitter] directly on twitter.
 [pborreli]: https://github.com/pborreli
 [aburgel]: https://github.com/aburgel
 [copitux]: https://github.com/copitux
+[areski]: https://github.com/areski
+[mindlace]: https://github.com/mindlace
diff --git a/docs/tutorial/6-viewsets-and-routers.md b/docs/tutorial/6-viewsets-and-routers.md
index 4ed10e82..f16add39 100644
--- a/docs/tutorial/6-viewsets-and-routers.md
+++ b/docs/tutorial/6-viewsets-and-routers.md
@@ -10,7 +10,9 @@ A `ViewSet` class is only bound to a set of method handlers at the last moment,
 
 Let's take our current set of views, and refactor them into view sets.
 
-First of all let's refactor our `UserListView` and `UserDetailView` views into a single `UserViewSet`.  We can remove the two views, and replace then with a single class:
+First of all let's refactor our `UserList` and `UserDetail` views into a single `UserViewSet`.  We can remove the two views, and replace then with a single class:
+
+    from rest_framework import viewsets
 
     class UserViewSet(viewsets.ReadOnlyModelViewSet):
         """
@@ -23,15 +25,14 @@ Here we've used `ReadOnlyModelViewSet` class to automatically provide the defaul
 
 Next we're going to replace the `SnippetList`, `SnippetDetail` and `SnippetHighlight` view classes.  We can remove the three views, and again replace them with a single class.
 
-    from rest_framework import viewsets
     from rest_framework.decorators import link
 
     class SnippetViewSet(viewsets.ModelViewSet):
         """
         This viewset automatically provides `list`, `create`, `retrieve`,
         `update` and `destroy` actions.
-        
-        Additionally we also provide an extra `highlight` action. 
+
+        Additionally we also provide an extra `highlight` action.
         """
         queryset = Snippet.objects.all()
         serializer_class = SnippetSerializer
@@ -73,7 +74,7 @@ In the `urls.py` file we bind our `ViewSet` classes into a set of concrete views
     })
     snippet_highlight = SnippetViewSet.as_view({
         'get': 'highlight'
-    })
+    }, renderer_classes=[renderers.StaticHTMLRenderer])
     user_list = UserViewSet.as_view({
         'get': 'list'
     })
@@ -107,7 +108,7 @@ Here's our re-wired `urls.py` file.
     router = DefaultRouter()
     router.register(r'snippets', views.SnippetViewSet)
     router.register(r'users', views.UserViewSet)
-    
+
     # The API URLs are now determined automatically by the router.
     # Additionally, we include the login URLs for the browseable API.
     urlpatterns = patterns('',
@@ -131,7 +132,7 @@ With an incredibly small amount of code, we've now got a complete pastebin Web A
 
 We've walked through each step of the design process, and seen how if we need to customize anything we can gradually work our way down to simply using regular Django views.
 
-You can review the final [tutorial code][repo] on GitHub, or try out a live example in [the sandbox][sandbox]. 
+You can review the final [tutorial code][repo] on GitHub, or try out a live example in [the sandbox][sandbox].
 
 ## Onwards and upwards