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 list_aggre
I'd be very happy with a change to give the full dotted path to the test.
I've copy/paste/modify/copy/paste hundreds of times, and it has always
bothered me. Big +1. Agree with Tim that a push upstream would be good, but
I'm all for solving this immediately in Django.
I think the suggestion mad
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.
https://code.djangoproject.
This list is for discussing the development of Django itself, please ask
usage questions on django-users.
On Wednesday, September 21, 2016 at 12:43:06 PM UTC-4, Patlola Praveen
wrote:
>
> class GroupPropertiesForm(forms.ModelForm):
> fields['equipment_grade']: forms.ChoiceField(
>
My reasoning is basically Alex Hill's. Subclassing for one bit of
functionality and using a callable for another is an inconsistent API, and
of the two, the callable is preferrable from a maintainability and
readability standpoint (for all the reasons he's already stated so well!)
On Tuesday, S
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 yo
class GroupPropertiesForm(forms.ModelForm):
fields['equipment_grade']: forms.ChoiceField(
choices=[(o.id, str(o))
for o in
GroupProperties.objects.all(group=???group???)]
class Meta:
model = GroupProperties
fields = ('group', 'bells')
widgets = {
Any feedback about my 2 proposals, to know if it is worth to spend time to
propose a patch for one of those?
Le mardi 5 juillet 2016 18:54:27 UTC+1, Romain Garrigues a écrit :
>
>
> Markus, I like the idea, which is definitely better than my idea of new
> option to recreate it manually when we k
Am Dienstag, 20. September 2016 13:30:33 UTC+2 schrieb Tim Graham:
>
> I haven't seen that proposal. This type of widget would be new territory
> for django.forms as none of the existing widgets require JavaScript. I lean
> toward keeping things that way, but I'm open to hearing counterargument
On Tuesday, September 20, 2016 at 5:28:46 PM UTC-7, Tim Graham wrote:
>
> I updated the Python issue to ask whether or not there's consensus to make
> the change there. Even if that issue proceeds, I guess it would be a nice
> convenience for current versions of Python that won't receive the chan
10 matches
Mail list logo
