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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
