Can we agree on the suggested design?
Or does anyone think it needs to be incorporated into *list_display*?
On Wednesday, September 21, 2016 at 7:43:06 PM UTC+3, dor wrote:
>
> I recently suggested adding a *list_aggregates* member to ModelAdmin,
> along with a patch to match:
>
I see much value in aggregating on a single page (rather than the entire
QS).
Check out this
example:
https://cloud.githubusercontent.com/assets/1499307/18555738/964622e0-7b71-11e6-9a53-3a525ba25b4b.png
Also, my current implementation (in the pull request) does support a
user-friendly name
We have an implementation of both annotations in *list_display* and adding
an aggregates for the entire list (which we call *list_summary* and what
you are calling here *list_aggregates*) and there are a bunch of subtleties
in the interaction due to Admin's built in support for pagination and
I think I'm OK with `list_aggregates` because it implies a terminal
queryset method which really restricts the members used to create that
aggregation (the GROUP BY). Adding aggregates to existing list_display
would require something *else* to refine the group by using `values()`.
If
How do you envision it interacting with ticket #14336 (annotations in
list_display)? Would we also need list_annotate? I'm a little sad every
time we add another customization point to the admin as I fear no end to
the complexity, but maybe I should just get over it.
I recently suggested adding a *list_aggregates* member to ModelAdmin, along
with a patch to match:
https://code.djangoproject.com/ticket/27229
A core developer counter-suggested changing the design of list_display to
achieve the same;
What do you think?
--
You received this message because
