Opened 6 years ago
Last modified 9 months ago
#29640 new Cleanup/optimization
Document (deprecate?) Paginator._get_page
Reported by: | Josh Schneier | Owned by: | nobody |
---|---|---|---|
Component: | Core (Other) | Version: | 2.1 |
Severity: | Normal | Keywords: | |
Cc: | Ülgen Sarıkavak | Triage Stage: | Accepted |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This has been undocumented since it was introduced in ~1.6 although it is meant for public use to override the Page class used by a Paginator.
Assuming we keep it (is anyone using it?) I think I like something along the approach of the generic views. We could add a get_page_class
method and a page_class
attribute although I wonder if the latter isn't enough. We'd need the former to maintain feature parity.
Change History (4)
comment:1 by , 6 years ago
Component: | Uncategorized → Core (Other) |
---|---|
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 6 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 6 years ago
I regret suggesting get_page
for the piece where we inlined the docs now. Maybe something like get_safe_page
would have been better. That is a minor issue, I do wonder if that particular aspect of the functionality is used.
comment:4 by , 9 months ago
Cc: | added |
---|
Moving to
get_page_class()
pluspage_class
seems reasonable._get_page()
, since it's been around a while. (Tim?)_get_page()
returns the instance whereget_page_class()
would presumably give us the class, which we then instantiate inpage()
.Not sure whether just having the attribute would be enough? Maybe someone is customising for first or last page, as one thought. We may as well leave it available (rather than needing to re-add it later.)