Opened 9 years ago
Closed 9 years ago
#24930 closed New feature (wontfix)
Add generic archive views for objects with DateRangeFields
Reported by: | Bence Nagy | Owned by: | nobody |
---|---|---|---|
Component: | Generic views | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Currently Django has generic views such as MonthArchiveView
for rendering a list of objects with a date field's value falling within a given timeframe.
Generic views such as this would be rather useful for objects whose place in time is determined with a date range, instead of a single date, such as subscription invoices specifying the dates covered, or multiple day events (say, a set of conferences).
Change History (4)
comment:1 by , 9 years ago
Summary: | Generic archive views for objects with DateRangeFields → Add generic archive views for objects with DateRangeFields |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Version: | 1.8 → master |
---|
comment:4 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
The behaviour of this would have several possible options, and I don't think it's a generic enough use case to deserve Django maintaining it. What happens when the range spans two months/years? Does it appear in both? Only one? If one based on what, start? end?
As a side note, I *think*, though I'm not completely sure, that the existing archive views can be used in the "only one" case by:
- Setting
date_field = 'range__start'
- Overriding
uses_datetimefield
if you are using aDateTimeRangeField
- Overriding
ordering
until such a time as transforms are supported in order by clauses (hopefully forthcoming).
For the "overlaps" case, a lot more work would be needed. At present the implementation of the archive views assumes a fixed point in time, and that every object would appear in only one view. For example, getting the list of possible sub views (month views for a year) which are non empty is a much harder process.
So, one possible use case is (nearly) covered by the built in view. The second is largely different, but could definitely live in a third party package. I'd rather keep contrib.postgres for database things and their form fields rather than adding any possible related concept.
Marc, what's your opinion about adding generic views to
contrib.postgres
?