Code

Opened 12 months ago

Closed 11 months ago

Last modified 11 months ago

#20235 closed Cleanup/optimization (fixed)

MultipleObjectMixin requires object_list to be passed in rather than using self.object_list

Reported by: dracos Owned by: MarkusH
Component: Generic views Version: master
Severity: Normal Keywords:
Cc: tinodb Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Unlike SingleObjectMixin, which uses self.object in its get_context_data, MultipleObjectMixin requires that object_list is passed in to get_context_data as a kwarg. BaseListView does this, but using MultipleObjectMixin separately requires this knowledge, not documented on the mixin page at https://docs.djangoproject.com/en/dev/ref/class-based-views/mixins-multiple-object/#django.views.generic.list.MultipleObjectMixin . It is alluded to at https://docs.djangoproject.com/en/dev/ref/class-based-views/generic-display/#django.views.generic.list.BaseListView but I don't think this is clear, and I think having it in MultipleObjectMixin is a better location, as with SingleObjectMixin.

As I assume MultipleObjectMixin is in use already with its current behaviour, I believe the nicest fix is to add a default to the pop() so that MultipleObjectMixin can be used by setting self.object_list in your subclass, the same as with SingleObjectMixin and self.object.

I have a patch on a branch of my github fork: https://github.com/dracos/django/compare/multipleobjectfixin

Attachments (0)

Change History (8)

comment:1 Changed 12 months ago by charettes

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

Was also bitten by this inconsistency. From a quick review the patch seems correct.

comment:2 Changed 12 months ago by tinodb

  • Cc tinodb added
  • Component changed from Uncategorized to Generic views
  • Type changed from Uncategorized to Cleanup/optimization

A question about the tests. Why are you testing that get_context_object_name works, and not that the correct queryset is used? The first two assertions would also pass without your changes, right? Or do I miss something?

comment:3 Changed 12 months ago by dracos

The second test (of object_list) would not pass without the change, because get_context_data() is called without arguments, and without the change that would throw an error as object_list wouldn't be present for the pop. The other tests were just to try and match the SingleObjectMixin test as much as possible.

comment:4 Changed 11 months ago by MarkusH

  • Owner changed from nobody to MarkusH
  • Status changed from new to assigned

comment:5 Changed 11 months ago by MarkusH

The test look fine to me. I rebased your patch onto the current master so that it merges cleanly and opened a pull request at https://github.com/django/django/pull/1083

Thanks for your work, dracos.

comment:6 Changed 11 months ago by mjtamlyn

  • Patch needs improvement set

As discussed at the sprint, the I share some confusion about what the tests are doing. In particular the customer context_object_name is not necessary, and also setting object_list as a class level variable is ugly.

comment:7 Changed 11 months ago by Markus Holtermann <info@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In 1c921cfac34daa9c18e4e235e20fa7beb8929f1c:

Fixed #20235 -- Use self.object_list if object_list not present in get_context_data kwargs.

This is so MultipleObjectMixin can be used in the same way as
SingleObjectMixin.

comment:8 Changed 11 months ago by Marc Tamlyn <marc.tamlyn@…>

In ef73a8eefd2c4836ca2badc67c3b9aa9a0add7bd:

Merge pull request #1083 from Markush2010/ticket20235

Fixes #20235 - MultipleObjectMixin requires object_list in kwargs

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.