From 57e9a36c3a05e42fbfb09889c9e4ce96420f64e6 Mon Sep 17 00:00:00 2001 From: Tom Christie Date: Fri, 7 Sep 2012 09:45:23 +0100 Subject: [PATCH] Tweak tutorial slightly --- tutorial/2-requests-and-responses.html | 4 +-- tutorial/3-class-based-views.html | 42 ++++++++++++++++---------- 2 files changed, 28 insertions(+), 18 deletions(-) diff --git a/tutorial/2-requests-and-responses.html b/tutorial/2-requests-and-responses.html index fab275356..b3cc1fba5 100644 --- a/tutorial/2-requests-and-responses.html +++ b/tutorial/2-requests-and-responses.html @@ -126,7 +126,7 @@ margin-top: 5px;
-

Tutorial 2: Request and Response objects

+

Tutorial 2: Requests and Responses

From this point we're going to really start covering the core of REST framework. Let's introduce a couple of essential building blocks.

Request objects

diff --git a/tutorial/3-class-based-views.html b/tutorial/3-class-based-views.html index 5782a36f1..413b9802c 100644 --- a/tutorial/3-class-based-views.html +++ b/tutorial/3-class-based-views.html @@ -126,17 +126,17 @@ margin-top: 5px;
-

Tutorial 3: Using Class Based Views

+

Tutorial 3: Class Based Views

We can also write our API views using class based views, rather than function based views. As we'll see this is a powerful pattern that allows us to reuse common functionality, and helps us keep our code DRY.

Rewriting our API using class based views

We'll start by rewriting the root view as a class based view. All this involves is a little bit of refactoring.

@@ -203,16 +203,16 @@ class CommentRoot(APIView): Okay, we're done. If you run the development server everything should be working just as before.

Using mixins

One of the big wins of using class based views is that it allows us to easily compose reusable bits of behaviour.

-

The create/retrieve/update/delete operations that we've been using so far is going to be pretty simliar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes.

-

We can compose those mixin classes, to recreate our existing API behaviour with less code.

+

The create/retrieve/update/delete operations that we've been using so far are going to be pretty simliar for any model-backed API views we create. Those bits of common behaviour are implemented in REST framework's mixin classes.

+

Let's take a look at how we can compose our views by using the mixin classes.

from blog.models import Comment
 from blog.serializers import CommentSerializer
 from djangorestframework import mixins
-from djangorestframework import views
+from djangorestframework import generics
 
 class CommentRoot(mixins.ListModelMixin,
                   mixins.CreateModelMixin,
-                  views.MultipleObjectBaseView):
+                  generics.MultipleObjectBaseView):
     model = Comment
     serializer_class = CommentSerializer
 
@@ -222,10 +222,14 @@ class CommentRoot(mixins.ListModelMixin,
     def post(self, request, *args, **kwargs):
         return self.create(request, *args, **kwargs)
 
-class CommentInstance(mixins.RetrieveModelMixin,
+comment_root = CommentRoot.as_view()
+
+

We'll take a moment to examine exactly what's happening here - We're building our view using MultipleObjectBaseView, and adding in ListModelMixin and CreateModelMixin.

+

The base class provides the core functionality, and the mixin classes provide the .list() and .create() actions. We're then explictly binding the get and post methods to the appropriate actions. Simple enough stuff so far.

+
class CommentInstance(mixins.RetrieveModelMixin,
                       mixins.UpdateModelMixin,
                       mixins.DestroyModelMixin,
-                      views.SingleObjectBaseView):
+                      generics.SingleObjectBaseView):
     model = Comment
     serializer_class = CommentSerializer
 
@@ -237,23 +241,29 @@ class CommentInstance(mixins.RetrieveModelMixin,
 
     def delete(self, request, *args, **kwargs):
         return self.destroy(request, *args, **kwargs)
+
+comment_instance = CommentInstance.as_view()
-

Reusing generic class based views

-

That's a lot less code than before, but we can go one step further still. REST framework also provides a set of already mixed-in views.

+

Pretty similar. This time we're using the SingleObjectBaseView class to provide the core functionality, and adding in mixins to provide the .retrieve(), .update() and .destroy() actions.

+

Using generic class based views

+

Using the mixin classes we've rewritten the views to use slightly less code than before, but we can go one step further. REST framework provides a set of already mixed-in generic views that we can use.

from blog.models import Comment
 from blog.serializers import CommentSerializer
-from djangorestframework import views
+from djangorestframework import generics
 
-class CommentRoot(views.RootModelView):
+class CommentRoot(generics.RootAPIView):
     model = Comment
     serializer_class = CommentSerializer
 
-class CommentInstance(views.InstanceModelView):
+comment_root = CommentRoot.as_view()
+
+class CommentInstance(generics.InstanceAPIView):
     model = Comment
     serializer_class = CommentSerializer
+
+comment_instance = CommentInstance.as_view()
-

Wow, that's pretty concise. We've got a huge amount for free, and our code looks like -good, clean, idomatic Django.

+

Wow, that's pretty concise. We've got a huge amount for free, and our code looks like good, clean, idomatic Django.

Next we'll move onto part 4 of the tutorial, where we'll take a look at how we can customize the behavior of our views to support a range of authentication, permissions, throttling and other aspects.