Changes between Initial Version and Version 1 of ClassBasedViews

Timestamp:

Sep 30, 2010, 11:58:36 PM (15 years ago)

Author:

Russell Keith-Magee

Comment:

Summary of work on Class-based generic views

ClassBasedViews

@@ +1 @@
+= Class-Based Views = 
+
+The proposal to add a class-based framework for describing views (#6735) has been around for a while. It's been proposed for inclusion in Django 1.0, 1.1, and 1.2. This is a summary of the state of debate, with the intention of landing a patch for the 1.3 release.
+
+== The brief ==
+
+At present, generic views are defined as methods. If you want to customize them, you have to pass in arguments to the view at time of use in urls.py. This is cumbersome:
+
+ * urls.py rapidly becomes large an unwieldly
+ * complex behaviors that need to be wrapped in callables depend on the underlying views handling callable arguments (which isn't implemented universally)
+ * There's no such thing as a simple extension -- you can't easily say "use that view, but change one argument"; you have to reproduce the full argument list.
+ * .. and much more 
+
+Moving to a class-based structure means that the complexities of defining and customizing generic views can be handled by subclassing. urls.py returns to being a simple process of pointing at a class. Extension logic can be arbitrarily complex, abstracted behind methods on the generic class. It also means we can provide an entry point for HTTP method-based dispatch -- e.g., a GET() method to handle GET requests, POST() to handle posts, etc.
+
+== The problem ==
+
+However, the devil is in the detail. There are several issues that any class-based view solution needs to address:
+
+ * '''Deployment''': How do you deploy an instance of the view
+ * '''URLResolver interaction''': Does the approach require any special handling in URLResolver to identify and/or instantiate the view?
+ * '''Subclassing''': How easy is it to subclass and override a specific method on a view class?
+ * '''Thread safety''': Does each request get a clean instance of self to work with? If so, how is this achieved?
+ * '''Ease of testing''': Does testing the view require any special handling (such as a specialized method to instantiate the view)
+ * '''Ease of decoration''': Does the proposed technique pose any impediments to easily decorating views?
+
+The [http://groups.google.com/group/django-developers/browse_thread/thread/e23d9a5a58fe5891 most recent django-developers discussion on the topic] discussed many of the available options. Here is a summary of the various approaches that have been proposed.
+
+=== !__call!__() and copy() ===
+
+[http://github.com/bfirsh/django-class-based-views Implementation]
+
+Example usage:
+{{{
+    url(r'^detail/author/(?P<pk>\d+)/$', views.AuthorDetail(), name="author_detail"),
+}}}
+
+Example class:
+{{{
+class AuthorView(View):
+    def GET(self, request, *args, **kwargs)
+        return self.render_to_response('author_list.html', {'authors': Author.objects.all()})
+}}}
+
+This approach proposes that an class instance be placed in urls.py; the instance has a !__call!__() method, and when that method is invoked, it takes a shallow copy of the instance defined in urls.py, and returns the result of invoking the request method (e.g., GET()). This achieves thread safety by ensuring that every request is given a clean instance on the view class to work on.
+
+No special handling is required in !UrlResolver -- the class instance is a callable, so it appears just like an existing view function.
+
+Arguments against:
+ * The "copy on !__call!__()" approach is a little messy. Normal Python idiom wouldn't lead users to expect that !__call!__() would cause a copy to be created. However, this is entirely hidden by the implementation.
+
+=== !__new!__() === 
+
+[http://github.com/fitzgen/django-class-based-views Implementation]
+
+Example usage:
+{{{
+    url(r'^detail/author/(?P<pk>\d+)/$', views.AuthorDetail, name="author_detail"),
+}}}
+
+Example class:
+{{{
+class AuthorView(View):
+    def GET(self, request, *args, **kwargs)
+        return self.render_to_response('author_list.html', {'authors': Author.objects.all()})
+}}}
+
+This approach is much the same as the !__copy!__() on !__call!__() approach, except that !__new!__() is used to create the new instance.
+
+Arguments against:
+ * You can't use arguments to __init__() to instantiate a class view
+ * x = !AuthorView() returns x as a HTTPResponse, not an !AuthorView instance. This violates expectations of normal class usage.
+
+=== HTTPResponse subclassing ===
+
+[http://github.com/roalddevries/class_based_views/ Implementation]
+
+This approach exploits the fact that the aim of a view is to produce a HttpResponse instance; so it shortcuts the process, and makes a 'view' the constructor for the !HttpResponse.
+
+Arguments against:
+ * Binds the Response object the concept of a view. A view isn't 'is-a' response, in the OO-sense.
+ * Makes it difficult or impossible to subclass !HttpResponse and use that subclass
+ * Makes it difficult to use !HttpResponse-returning methods; you can't just call out to a subview/utility method that returns a !HttpResponse instance, because the view needs to return 'self'.
+
+=== !UrlResolver view instantiation ===
+
+Rather than try to make the view look like a callable, this approach modifies !UrlResolver so that it can identify when a class-based view is in use, and instantiate an instance when one is detected.
+
+Arguments against:
+ * Requires special cases in !UrlResolver which almost inevitably involve isinstance(!ViewClass) or some analog.
+
+= Recommendation =
+
+Based on these discussions, plus in-person discussions at !DjangoCon.eu,  !__copy!__() on !__call!__() appears to be a slight front runner, with !__new!__() as a close runner up.