Thanks to everyone who's helping push this forward. I would get stuck in, but I'm bogged down with work at the moment.
A couple of things from the wiki page that need doing: 1) Test coverage probably isn't great. Everything seems to work when I've used it in applications, but there's probably some stuff in there that isn't thoroughly tested. 2) Support for ModelForms isn't quite the same as our current generic views. For edit views, you can specify a model and the form is optional. Ben On 5 Oct 2010, at 15:43, Jacob Kaplan-Moss wrote: > On Tue, Oct 5, 2010 at 8:03 AM, Russell Keith-Magee > <russ...@keith-magee.com> wrote: >> Ok - so to kick the process into the next phase, I've just created a >> Django branch in my bitbucket repo [1] to cover introducing this to >> trunk. > > I gave this a quick review and nothing huge jumped out. Looks good so far. > > One point of concern that came up though: looking at the way as_view > introduces a closure, it occurs to me that the docstring of am > as_view'd class view isn't very useful, which'll break introspection > and things like the admindocs tool. And just using functools.wraps (or > the equivalent) is as_view won't exactly work, either: you'll get the > dispatch() docstring instead. > > So unless anyone can think of a reason why it'd be a bad idea, I think > as_view needs to monkeypatch the class's docstring into the returned > closure. Bit of a code smell, but I think it maintains the correct > self-documenting nature of a view, yeah? > >> * Does RequestFactory need to be added to Django's test tools >> (Possibly fixing #9002)? > > I'm not sure it's directly class-based-views-related, but I believe it > should, yes. It's a useful pattern that makes it into a utils module > in nearly every app I write. > >> * Does django.views.generic.utils.coerce_put_post() indicate a change >> that needs to be made in Django? (Is there an existing ticket for >> this?) > > Yeah, this has been a wart in Django for a while -- Django doesn't > really "get" PUT very well. Along the same lines, > request.raw_post_data is terribly named. I don't know that there's a > single ticket anywhere, but I'd like to see a general cleanup here. > > I don't see this as a blocker for class-based views, though: we have a > narrow feature deadline that I'd like to hit, and then a longer > bug-fix period we can use to clean up PUT/POST and such. > >> * Are there any outstanding tickets on generic views that will be >> closed by merging this branch, and do they ask for any features that >> aren't fixed by this branch? > > Almost certainly yes :) > > We could *really* use a volunteer who can wade through the open > tickets, look at all the GV-related tickets, and answer this question > concretely. > > Anyone? Bueller? > > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
