chipx86 got review request #9000!

Move the user infobox view into accounts/ and make it class-based.

Review Request #9000 — Created June 6, 2017 and submitted

Information

Review Board
release-3.0.x
2bbd4dc...

Reviewers

The user infobox has lived in reviews/ for a while now, but it's not
specific to review requests. The accounts/ module is a better place for
it. This change moves it there and also converts it to use class-based
generic views, making use of the new mixins offered by Djblets and
Review Board for access restrictions.

Tested that the view still works, obeys access restrictions, and handles
ETag caching.

Description From Last Updated

Can we create an __init__ that sets None values for the cached data (like self._lookup_user), and then assert on their …

daviddavid
david
  1. 
      
  2. reviewboard/accounts/views.py (Diff revision 1)
     
     
    Show all issues

    Can we create an __init__ that sets None values for the cached data (like self._lookup_user), and then assert on their contents before they're accessed? Right now it's a little bit hidden what data gets stored, and while we're always supposed to have get_etag_data called before get_context_data, it would be nice to enforce it.

    It would also be nice to unset that cached data after the dispatch is done.

    1. Yep, I'll make the __init__ changes.

      As for clearing out after, there's no need. Views are a bit special. The data doesn't actually persist between requests (or we'd have threading issues). Instead, what happens is that as_view() (the method called in urls.py) returns a function that acts as the view. When invoked, a new instance of the class is created, some state set, and then dispatch() is called. It's then thrown away. So it's safe to store whatever you want on the view.

  3. 
      
chipx86
david
  1. Ship It!
  2. 
      
chipx86
Review request changed
Status:
Completed
Change Summary:
Pushed to release-3.0.x (67099a7)