#6735: Class-based generic views
------------------------------------+---------------------------------------
          Reporter:  jkocherhans    |         Owner:  telenieko
            Status:  assigned       |     Milestone:  1.2      
         Component:  Generic views  |       Version:  SVN      
        Resolution:                 |      Keywords:           
             Stage:  Accepted       |     Has_patch:  1        
        Needs_docs:  1              |   Needs_tests:  0        
Needs_better_patch:  0              |  
------------------------------------+---------------------------------------
Changes (by mmalone):

 * cc: [email protected] (added)

Comment:

 I think documenting the use of class-based views and providing a simple
 implementation would be a great addition to Django, but I don't think this
 is the right approach.

 I've seen two methods of implementing class-based views, `__call__` based
 and `__init__` based. The attached patch uses the `__call__` approach.
 Here's a quick example of an `__init__` based class-view:


 {{{
 from django.http import HttpResponse

 class BaseView(HttpRespones):
     def __init__(self, request, *args, **kwargs):
         content = self.get(*args, **kwargs)
         super(MyView, self).__init__(content)

     def get(self):
         return 'Hello, world!'
 }}}

 The big gain here is that Django will instantiate a view instances per
 request, so you can actually store state in view objects. The `__call__`
 based approach can be misleading/dangerous/confusing in this respect since
 the view instance is a global object that will be retained between
 requests. Even if you reset the state of the object at the beginning of
 each request, it's process local so it isn't thread safe.

 The only thing the `__init__` approach complicates is passing default
 arguments in during instantiation (e.g., model and post_save_redirect in
 the attached patch), but the url() function already solves that problem
 for function-based views by providing the kwargs argument, which works
 equally well here.

 Unless anyone can think of some benefit to using the `__call__` approach,
 I'd suggest we use `__init__` instead.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/6735#comment:37>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to