Opened 3 years ago

Last modified 7 months ago

#17209 new Cleanup/optimization

Dogfood class-based views in contrib.auth

Reported by: melinath Owned by: andrews
Component: contrib.auth Version: master
Severity: Normal Keywords: class-based views admin auth
Cc: dstufft, seldon, andrewsmedina@…, bmispelon, vlastimil.zima@…, marc.tamlyn@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Right now, the views provided by contrib.auth are not very extensible, since they are still functional. It would be great to add class-based versions which could eventually replace the functional versions. This is related to #17208; when this change is made, the admin login view should be tweaked to extend the new view.

Attachments (1)

patch.diff (24.4 KB) - added by japrogramer 7 months ago.
this patch changes the auth view functions to CBV, maintaining backwards compatibility and tests passing ;)

Download all attachments as: .zip

Change History (24)

comment:1 Changed 3 years ago by ptone

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 3 years ago by dstufft

  • Cc dstufft added

I'm taking a crack at this. I've started working on it in my branch on github: https://github.com/dstufft/django/tree/feature/contrib-auth-cbv

So far i've gotten the LoginView switched to a CBV with a shim to translate login -> LoginView and switching the auth specific kwarg names to match the more generic kwarg names in FormView.

comment:3 Changed 3 years ago by seldon

  • Cc seldon added

comment:4 Changed 3 years ago by andrews

  • Cc andrewsmedina@… added
  • Owner changed from nobody to andrews

comment:5 Changed 3 years ago by bmispelon

  • Cc bmispelon added

I've made some pogress on this: https://gist.github.com/1851113

It still needs tests and documentation but I'm hoping to work on it during the sprints at djangocon europe next month.

comment:6 follow-up: Changed 3 years ago by andrews

bmispelon I can help you with that. You could add me to your fork on github?

comment:7 in reply to: ↑ 6 Changed 3 years ago by bmispelon

Replying to andrews:

bmispelon I can help you with that. You could add me to your fork on github?

I made a proper fork of django's new github repo: https://github.com/bmispelon/django and committed my changes.

comment:8 Changed 3 years ago by bmispelon

After two minor modifications, I've got all the tests passing on my fork.

There are still a few things I'd like to improve, mostly around the redirection logic in LoginView and LogoutView (it's still messy).

I've had a hard time wrapping my head around the flow of the function-based logout view. I'd appreciate it if someone could make sure I did actually replicate it.

I also have a few questions:

  • LogoutView: For now, it inherits from TemplateView. Does it make more sense to inherit from RedirectView (RedirectView has the nice advantage of dispatching POST, OPTIONS, DELETE, and PUT to GET)? Or maybe simply View?
  • PasswordResetConfirmView: as mentionned in the comment on the code, there is a potential backwards-compatibility issue. It should not be too hard to correct it but is it really a problem?
  • Backwards-compatible stubs: the approach I took to ensure backwards-compatibility was to create function based wrappers around the class-based views. Is this a good approach?
  • How do I approach writing tests for these new class-based views? I'm having a hard time determining what should be tested and how.

comment:9 Changed 3 years ago by bmispelon

I've made some more improvements and reached a point where I'm pretty satisfied with the code.

I'm going to attempt writing some documentation now, using the work done by pydanny in the pull request #144 (it hasn't been accepted yet as I'm writing this).

comment:10 Changed 3 years ago by anonymous

Also check out #16197 which has been closed as a duplicate of this ticket.

comment:11 Changed 3 years ago by vzima

  • Cc vlastimil.zima@… added

comment:12 Changed 3 years ago by mjtamlyn

  • Cc marc.tamlyn@… added
  • Patch needs improvement set

I've tried bringing the patch up to the current master. Most of the tests pass and it seems to be ok, but there's something weird going on with the way that the wrapper shim works.

On discussion with andrewgodwin we've come up with the following changes:

1) Remove the wrapper shim, and convert all of the keyword arguments to kwargs. We can handle extra_context by updating the context on the TemplateResponse object returned from the CBV.

2) Tests: the new tests should be entirely equivalent to the old tests, but also separate. So a new set of urls linked to the cbv views, and retest all the expected behaviour. We should then be able to deprecate things easily when the time comes.

3) Docs/Release notes. The functional views documentation can be removed, and we can convert each part of the docs to now document the new, class based version.

comment:13 Changed 3 years ago by mjtamlyn

Ok, I've got all of the tests working again and updated the wrapping of the new views with the old ones.

The code is visible here: https://github.com/mjtamlyn/django/compare/auth-cbv

The last thing to add to the list above is integrating these changes with the rest of django. The auth views are used by the admin, flatpages and other parts of auth and these should be updated to use the new cbv approach.

comment:14 Changed 2 years ago by ptone

an interesting related bit to note here - is making the password reset process more flexible for custom users via CBV views:

http://pypi.python.org/pypi/django-password-reset

via

https://groups.google.com/forum/?fromgroups=#!topic/django-developers/NNnDVzoNQbU

comment:15 Changed 2 years ago by bmispelon

I just pulled master back into my branch:
https://github.com/bmispelon/django/compare/auth-cbv

I thought the new swappable user model would break a lot of things but it turned out much easier than expected.

I've been looking into moving contrib.admin to use the new CBV but what I have so far is pretty ugly because the admin uses a lot of the old extra_context parameter, which requires CBV to create a get_context_data method.

As for flatpages, it only uses redirect_to_login which we didn't touch.

comment:16 Changed 2 years ago by claudep

It looks nice. It would be nice to rebase/merge the commits, write some documentation and generate a pull request so we can comment on it.

comment:17 Changed 21 months ago by rockymeza

I opened a pull request for this ticket https://github.com/django/django/pull/1239

This pull request is different from https://github.com/bmispelon/django/compare/auth-cbv in a couple ways:

  1. There is no wrapper shim. The views extract the old parameters from kwargs. This has the benefit of subclasses still supporting the old view invocation.
  2. It uses the DecoratorMixin pattern described in https://groups.google.com/d/msg/django-developers/jrfbenCJYYU/6aiH2sebnlAJ. This is controversial, yes, but it does mean a subclass will never lose its decorators should someone override dispatch.
  3. It is rebased on master.


I was going to write some documentation for the class-based views, but I was wondering if we should maintain (and keep documented) the function view kwarg parameters or if they should be truly deprecated. All access to those function view kwarg parameters is regulated through one piece of code, so it would be possible to deprecate them easily. I'm in favor of deprecating the function view kwargs, 1) because they are terribly inconsistent (post_reset_redirect vs. post_change_redirect) and 2) to embrace the established class-based views APIs.

comment:18 Changed 21 months ago by mjtamlyn

I'm not particularly fond of the approach you've taken here. I think we should not be trying to support some of the more obscure customisation points which existed historically. I agreed with some of the other core devs that the best way to proceed is to leave the old code as is, but with deprecation warnings, and create new views which are well designed to the new way of doing things, and provide a more consistent feeling API to the main GCBVs.

Other points:
If we're going to include the DecoratorMixinthen we should include it in a more logical place in the code base
Patch is completely missing tests - the tests for auth views are not complete as it is, so they need expanding to cover all the branches as well. Also they need to check all the deprecated views still work.
There are lots of minor style points - for example the use of resolve_url rather than reverse

comment:19 Changed 21 months ago by bmispelon

Hi,

I worked with Marc on this issue during the sprints at Djangocon Europe last month (and last year too).
Admitedly, I haven't made much progress on this since, but I haven't given up and I still work on it from time to time.

As it's often the case, writing the code is the easier part. I think the code we have is pretty good now and I don't see much advantage in tweaking it further (except maybe the idea of using the DecoratorMixin, see later).

As Marc mentionned, we've more or less settled on the idea of creating plain CBV, without any backwards-compatibility layer.
We would then keep the old function-based views around, with a deprecation warning as per the deprecation policy.
This allows us to start on a relative clean slate and get rid of the cruft that's been added over the years.

With the code settled, what's preventing this ticket from moving further has more to do with things like tests, documentation, and other parts of django that need to be cleaned up.

For example, there are a few places in django that assume the presence of function-based views inside contrib/auth/views.py so those need to be fixed (I'm currently working on this).
There's also the issue of the admin which makes heavy use of the auth views and their configuration options. In particular, it uses extra_context which doesn't map well to class-based views.

One thing to note is that with this rewrite, django.contrib.auth would become the first app in django that ships with non-generic class-based views.
This means that we need to come up with a way of both documenting and testing these views.
This is not completely straighforward, especially considering that whatever we come up with would probably be regarded as some sort of canon on how to test/document non-generic class-based views.

Personally, I'd rather take some more time and do this properly (clean up the code, tests and doc) rather than cut corners and ship something still half-broken with backwards-compatibility cruft.

Finally, regarding the DecoratorMixin:
I like the idea but I wonder if shouldn't be in a separate ticket.
I think the feature makes sense on its own and with the more litmited scope that it has,
it would stand a better chance of getting commited separately.

Thanks.

comment:20 Changed 21 months ago by bmispelon

I just pushed all the things I had left from the sprints onto https://github.com/bmispelon/django/compare/master...auth-cbv (I also merged the latest changes from master).

Here's what needs to be done next:

  • Move all the contrib.auth.test_views to a new test_legacy_views file.
  • Come up with a way of testing the class-based views (2 things need to be tested separately: the fact that the view itself works as intended, and its extension points).
  • Document the new class-based views.
  • Fix contrib.admin's usage of the auth views. As I mentionned before, the usage of the old extra_context parameter is what's causing problems here.

Out of these 4 points, only the first one is fairly easy (it's just some heavy copy/pasting and moving files around). The other 3 will be more tricky and I worry that the fixing of contrib.admin might unveil some more complicated issues.

Changed 7 months ago by japrogramer

this patch changes the auth view functions to CBV, maintaining backwards compatibility and tests passing ;)

comment:21 Changed 7 months ago by japrogramer

(above) just attached a file with my improvements on the auth views, they are now CBV and have function gateways to maintain backwards compatability but users can easily import the CBV and override functions to extend or modify functionality :D

comment:22 Changed 7 months ago by japrogramer

  • Has patch set
  • Needs tests set

comment:23 Changed 7 months ago by japrogramer

  • Needs tests unset
Note: See TracTickets for help on using tickets.
Back to Top