#16218 closed Bug (fixed)
Class-based month archive doesn't behave like previous generic view
Reported by: | Ernesto Rico-Schmidt | Owned by: | Aymeric Augustin |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
While converting some of the regression tests for generic views to class-based views, I've noticed that the class-based month archive doesn't behave like the previous generic views.
Applying the attached patch breaks the tests:
FAIL: test_archive_month_date_list (regressiontests.views.tests.generic.date_based.MonthArchiveTest) ... AssertionError: datetime.datetime(2010, 1, 2, 0, 0) != datetime.datetime(2010, 1, 1, 0, 0) FAIL: test_archive_month_includes_only_month (regressiontests.views.tests.generic.date_based.MonthArchiveTest) Regression for #3031: Archives around Feburary include only one month ... AssertionError: None != datetime.date(2004, 3, 1)
Attachments (3)
Change History (15)
by , 14 years ago
Attachment: | ticket-16218.diff added |
---|
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Quick digging reveals that the old generic views do
date_list = queryset.dates(date_field, 'day')
while the new one does
date_list = queryset.dates(date_field, date_type)[::-1]
So, the two dates tested are just sorted differently apparently. The questions are: why? and does it hurt?
by , 14 years ago
Attachment: | django-16218.asctest.diff added |
---|
comment:3 by , 14 years ago
Triage Stage: | Unreviewed → Accepted |
---|
According to the docs at https://docs.djangoproject.com/en/dev/ref/class-based-views/#montharchiveview, date_list should be ordered ascending. Seems like that is not the case, I added a test for ascending order in the generic CBV tests, which gives:
FAIL: test_date_list_order (regressiontests.generic_views.dates.ArchiveIndexViewTests) date_list should be ascending ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/bpeschier/dev/python/envs/django-dev/django-trunk/tests/regressiontests/generic_views/dates.py", line 83, in test_date_list_order self.assertEqual(res.context['date_list'], list(sorted(res.context['date_list']))) AssertionError: Lists differ: [datetime.datetime(2011, 1, 1,... != [datetime.datetime(2006, 1, 1,...
by , 14 years ago
Attachment: | django-16218.diff added |
---|
comment:4 by , 14 years ago
Has patch: | set |
---|
Patch updates generic CBV to sort date_list
in basic index view descending and year/month view ascending. It also adds tests to check the order. This covers the first fail in the report.
The second fail is a different story: in the generic CBV code there is a section about preventing to link to empty pages [1]. Conforming to that, the patch contains an update for the docs to clarify that behaviour with the allow_empty
setting. This is different from the old generic views, where this data is given even if allow_empty
is False
.
[1]: https://code.djangoproject.com/browser/django/trunk/django/views/generic/dates.py?rev=16363#L520
comment:6 by , 13 years ago
Owner: | changed from | to
---|
comment:7 by , 12 years ago
Patch needs improvement: | unset |
---|
I just reviewed the history of this ticket and updated the patch. Pull request: https://github.com/django/django/pull/362
The documented order seems much more logical to me than the implemented order. Like nnrcschmdt and bpeschier, I'd prefer to restore the documented order, even though it introduces a backwards incompatibility.
As an unscientific datapoint, I always reverse date_list
in year and month views in my templates; when we fix this ticket I'll be able to remove that code.
comment:9 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Could you be a little bit more specific?
I trust that applying this patch breaks the tests, but it's difficult to determine if that means the code does not behave according to the docs and/or obvious expectations.