Class-based generic views

This ticket refs #3639 use newforms in generic create_update view

The tests need to be fleshed out a little more, and we need a plan for backwards compatibility, but the classes themselves are fairly close, I think.

Discussion here: http://groups.google.com/group/django-developers/browse_frm/thread/da37ad5cb842431f

post_save is now on_success and I've added hook to return the rendered template.

Sorry about the mess of patch files. I forgot to check the "replace me" box. Anyhow, Adrian and Jacob are both in favor after a discussion today, so I'm changing status to Accepted.

Now list_detail views can play too.

The EditView? class is passing back a exception when I use it with a model that has a field with editable set to False (editable=False). I'm only starting out with python so please ignore this if the problem is at my end.

Traceback is here... http://dpaste.com/41195/

This is great. it looks like one of the frequent patterns I'll be seeing is having to add some context vars a la extra_context. Presently I'm adding a render_response to the subclassed view and doing it there, might be nice to support a get_context_vars()

I think views as classes is a huge feature, might be nice to have the generic views inherit from a BaseView? and BasePaginate? view, etc. Personally the application I'm working on has a lot of pages with forms that filter the view somehow, so there will be a huge number of view subclasses.

Is anybody working on the docs for this? If not I'll try to give it some time later. (No need to reply "no", just reply if "yes" ;))

class hierarchy

Attached a possible class hierarchy. Not that what is drawn as class members are what would be passed to call() as parameters (it was easier to draw it this way).

For anyone interested in this ticket (scheduled post-1.0) current code (in-progress) can be taken from my git branch, raw, non-colored diff here.

Current code should be usable (passes tests). And provides wrappers to the old views, so if you can; Try the patch without touching your urls and let me know what happens.

Question of the day, mostly for jacob and jkocherhans (it's DDN):

• Would you agree to add to DetailView? and ListView? (see current diff) an extra option: "allow_serialization" (and maybe "serialization_format='json'") and then, in the call() do:

  if request.is_ajax() and self.allow_serialization:
    return serialized_stuff()

This is a pretty common pattern (if the request is AJAX return the object_list, or the object serializaed) and actually requires doing wrappers, and with this ticket would mean people needing to do their own classes, so it would be nice to provide this (disabled by default).

It's generic! and simple, and disabled by default, but avoids needing wrappers/inheritance to get such a common thing ;) (Would also allow YUI, dojo, etc to provide better integration as there would be a standard way to get data for grids, etc from django).

Replying to telenieko:

Question of the day, mostly for jacob and jkocherhans (it's DDN): * Would you agree to add to DetailView? and ListView? (see current diff) an extra option: "allow_serialization" (and maybe "serialization_format='json'") and then, in the call() do:

This seems more in the realm of the various REST projects going on, so I'd be -0. People are going to want to control which fields are serialized, and that is definitely out of scope for DetailView and ListView.

is the definition for ObjectListView? not committed to base.py? I don't know how to use git yet, perhaps I'm missing something.

Replying to R. Bailey <bailey@akamai.com>:

is the definition for ObjectListView? not committed to base.py? I don't know how to use git yet, perhaps I'm missing something.

I assume you refer to the imports in django/views/generic/list_detail.py, that was a typo I renamed ObjectListView? and ObjectDetailView? to ListView? and DetailView? to make them shorter.

Thanks for spotting the typo, that means there are more tests needed ;)

good deal, thanks. I'll sync up.

With 1.0 on the streen it's time to start with the killer features for 1.1 (yes I intend this one to go for 1.1 ehehe).

Question one: Would you love a ListEditView?() which used FormSets? to edit/create multiple objects? (Just like an EditView? but for more than one form).

Question mostly for Jacob: The documentation for the class based generic views (see current docs diff) has to document all the methods available for inheritance which makes the document itself a bit cumbersome (lots of details that people wanting to "just use" those views are not interested in). So, would it be reasonable to do a topics/generic-views.txt with the introduction and the usage details; And then put on ref/generic-views.txt the implementation details and how can one inherit/develop generic views on top of the new ones?

That's my main goal for 1.1 too. I hardly can find time for now but I keep an eye on it. Thanks for taking this.

For the record, from IRC conversation:

Replying to telenieko:

Would you love a ListEditView?() which used FormSets? to edit/create multiple objects? (Just like an EditView? but for more than one form).

That would be another ticket after this one gets in.

Would it be reasonable to do a topics/generic-views.txt with the introduction and the usage details; And then put on ref/generic-views.txt the implementation details and how can one inherit/develop generic views on top of the new ones?

Jacob is planning to do so for current generic views, so I'll do so for those ones.

Milestone post-1.0 deleted

Looks like this won't make it; I didn't get it done.

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.

Replying to mmalone:

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:

Hi mmalone, This is getting a major re-thing/re-write by Jacob, taking an approach much more like Model classes, if I remember correctly, the thing was something like:

from django.views.generic import ListView

class MyListView(ListView): 
    # Base view for views that list objects
    queryset = MyModel.objects.all() 
    paginate_by = 30    
    # You may override some methods here.

Then you'd pass the MyListView? class to the URL patterns. init() would get URL parameters, while view configuration (what the current code here passes to init() would be on the class definition.

It's much more like Model classes, the only drawback is that you need to define you view class even for really simple stuff. But complex things get much nicer ;)

Hope Jacob can push current code sometime soon for everyone to see.

Thanks for commenting!

Jacob's code is on github account.

Anyone have a link to Jacob's code on github? I checked his projects but couldn't find it easily.

telenieko: re simple things becoming harder, you'll still be able to make function-based views so that's not really true!

It's in a branch of his fork of django: http://github.com/jacobian/django/tree/09cd9de875ee7a2d8f293329a69a2ca351445262/django/views/generic2

Replying to Alex:

Jacob's code is on github account.

Thanks! I should do "git remote update" more often :)

Replying to mmalone:

telenieko: re simple things becoming harder, you'll still be able to make function-based views so that's not really true!

I think those will be deprecated in favour of the class based ones.

Replying to telenieko:

I think those will be deprecated in favour of the class based ones.

That's kind of dumb. Django has always supported both, why explicitly "deprecate" one method when they're both well supported.

Also, I just took a look at Jacob's code and it looks like he's using the __call__ based approach, so my comments from above still apply. If you tell someone to write a class they're going to want to store state in instances, and I think that's going to be problematic.

Mike, he means the function generic views will be deprecated, not views in general.

Ah, ok. That makes more sense.

I've just been poking through the branch on GitHub? and it looks great, but just in the name of API consistency it looks like the API for the class based views does not match the API for Syndication Feeds.

Namely, in a feed, if you want to override (for example) 'title' you can either provide a method or a string and the feed will handle either value intelligently.

In the class based views (so far), if you want to override (for example) 'items' you can either set 'items' or you can override the method get_items. This isn't consistent.

I'm not sure if this is an issue but I thought I'd point it out.