Changes between Version 9 and Version 10 of ClassBasedViews

Timestamp:

Oct 4, 2010, 1:54:19 PM (14 years ago)

Author:

Luke Plant

Comment:

--

ClassBasedViews

@@ -36 +36 @@
 Alternatively, override `__getattr__/__setattr__` to access `self.request.state` under the hood while on the surface it looks as if the state is stored on the view instance.
 
-Example usage and view would be the same as shown below in "__call__ and copy()".
+Example usage and view would be the same as shown below in "`__call__` and copy()".
 
 Arguments for:
@@ -62 +62 @@
 }}}
 
-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.
+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.
- * The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an !__init!__ method (common practice). If any of the state they attach to self in !__init!__ is mutable (list, dict, object, etc) and they mutate it in the view, this will fail (but not immediately, or in obvious ways).
+ * 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.
+ * The abstraction of the copy-on-call can leak in surprising ways. Some users will try to set up state using an `__init__` method (common practice). If any of the state they attach to self in `__init__` is mutable (list, dict, object, etc) and they mutate it in the view, this will fail (but not immediately, or in obvious ways).
 
-==== !__new!__() ====
+==== !__new!__()` ====
 
 [http://github.com/fitzgen/django-class-based-views Implementation]
@@ -86 +86 @@
 }}}
 
-This approach is much the same as the !__copy!__() on !__call!__() approach, except that !__new!__() is used to create the new instance.
+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.
+ * You can't use arguments to `__init__()` to instantiate a class view (although you can add a `configure` class method to replace this usage)
+ * `x = AuthorView()` returns x as a HTTPResponse, not an `AuthorView` instance. This violates expectations of normal class usage.
+
+==== classmethod ====
+
+[http://github.com/spookylukey/django-class-based-views Implementation]
+
+Example usage:
+{{{
+    url(r'^detail/author/(?P<pk>\d+)/$', views.AuthorDetail.as_view, 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 is very similar to the `__new__()` approach, except that we have to add a classmethod call to create the callable.
+
+Arguments against:
+ * You can't use arguments to `__init__()` to instantiate a class view (although you can add a `configure` class method to replace this usage)
+ * The URLconf is slightly more verbose
 
 ==== HTTPResponse subclassing ====
@@ -109 +131 @@
 Arguments against:
  * Requires special cases in !UrlResolver which almost inevitably involve isinstance(!ViewClass) or some analog.
- * Decorators become extremely difficult to use; wrapping methods or __call__ on an uninstantiated class is hard.
+ * Decorators become extremely difficult to use; wrapping methods or `__call__` on an uninstantiated class is hard.
 
 ==== 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.
+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.
 
 === Class Hierarchy ===