Using views externally to `.as_view()` sounds like a potential pitfall to me - I would not suggest that this is part of the public API of a view. Is this in testing code, or production?
As for the change itself, this was precisely done *because* we want people to override `dispatch()` - the issue was that I could not override dispatch and then call, say, `get_object()` without duplicating some lines from `dispatch()`. I agree that the API has changed slightly, and it's now much closer to its actual purpose - choose which method handler to call and call it. It also acts as a hook for method-independent code. Also, as that change has been released in 1.5.X for several months, it's likely to late to back out of it without really good reason. I hope that makes sense? On 19 August 2013 14:52, Jonas Maurus <jonas.mau...@gmail.com> wrote: > Hey everyone, > > #19316, or more specifically > https://code.djangoproject.com/changeset/12cf9d2be3cccb2ff63d78e93f97188040488a3dseems > to have broken the documented API of View. > > In > https://docs.djangoproject.com/en/dev/ref/class-based-views/base/#django.views.generic.base.View.dispatch, > dispatch() seems to be part of the external API of View. We happen to call > dispatch() directly on View subclass instances in django-flows ( > https://github.com/laterpay/django-flows, specifically > https://github.com/laterpay/django-flows/blob/develop/flows/handler.py#L413). > Due to the change set above, calling dispatch() on FormView subclasses will > now always fail as FormView expects self.request to be set, but that will > only happen in the closure returned by as_view(). > > I think that the change in #19316 should be backed out or alternatively > dispatch() should be removed from the public API as _dispatch, at which > point the constructor to View() should also be made private. Right now > however, people are encouraged to override dispatch() in subclasses, so I > think the change is just broken. > > To summarize: Unless I missed something, it seems to me that dispatch > can't be reliably called from the outside without setting up the instances > .request, .args and .kwargs attributes. > > I hope somebody here can take a look and tell me if I'm way off course or > whether this is a legitimate bug :). > > Thanks and best regards, > Jonas > > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
