Django YearArchiveView date appearance
There is a generic view in Django YearArchiveView
that has the attribute make_object_list
.
Can someone explain to me why this option even exists?
Isn't it logical that if I want a set of queries based on a year, then obviously I need a list of objects, even if it only has one object. Or am I misunderstanding something here.
source to share
TL; DR; make_object_list
returns all objects for the given YearArchiveView in the context of the view in object_list
. The default make_object_list
is False, which will cause the returned context to object_list
be empty.
So the django documentation is a bit tricky to understand for this part. But hopefully it helps (hint: looking at the source code does help).
YearArchiveView
will by default return the following in context:
- date_list: a set of date queries that return all months that have objects.
- year: a date object for the given year.
- next_year: a date object for the first day of the next year.
- previous_year: a date object for the first day of the previous year.
In this list, you will see that query objects for a given year are empty at the time they are returned.
make_object_list So, from the above, we know that the default context will return a range of values related to the dates of objects, current year, previous and next, but not the actual query objects from the database.
Setting it make_object_list
to true on the YearArchiveView will cause all query objects for the given year to be passed back through the context so that they can be used in the view.
Within the template, the request objects will be available in the context object_list
.
If in the template for a given YearArchiveView you can use:
{% for item in object_list %}
<strong>item.title</strong> - {{ item.date }}
{% endfor %}
source to share
In addition to @MattWritesCode answer, I would say that there are cases where you are only interested in creating navigation and not including most of the real objects.
I imagine myself doing thousands of articles like big newspapers. Most likely I want to display the actual content in a separate view that supports paging (and possibly fine-grained permissions access like public posts and posts for a fee).
Good question though, I'm just thinking about it. Since the queries are lazy, I would not expect this to be a big performance gain, but perhaps somehow this is an aspect too. It would be interesting to know more about this.
source to share