Fellow Report - July 2, 2016
Triaged --- https://code.djangoproject.com/ticket/26807 - Document how to replicate SubfieldBase behavior of calling to_python on assignment (accepted) https://code.djangoproject.com/ticket/26813 - ModelForm RadioSelect widget for foreign keys should not present a blank option if blank=False on the model (accepted) https://code.djangoproject.com/ticket/26820 - Reverse join in `exclude` fails when GenericRelation is defined on an abstract model (duplicate) https://code.djangoproject.com/ticket/26812 - APPEND_SLASH doesn't work with URLs that have query strings (wontfix) https://code.djangoproject.com/ticket/26815 - Addition of Trunc may have altered the ordering of dates() queries (needsinfo) https://code.djangoproject.com/ticket/26822 - New migrations not applied on clone databases (sqlite) when using --parallel and --keepdb option (accepted) https://code.djangoproject.com/ticket/26826 - dumpdata command using multiple pks that are UUIDs produces error (accepted) https://code.djangoproject.com/ticket/26825 - MultipleObjectMixin and DB don't work together (invalid) https://code.djangoproject.com/ticket/26823 - auth signal receiver update_last_login not compatible with custom user models that have no last_login field (accepted) Authored https://github.com/django/django/pull/6841 - Replaced use of TestCase.fail() with assertRaises(). Reviewed/committed -- https://github.com/django/django/pull/6726 - Fixed #26709 -- Added class-based indexes. https://github.com/django/django/pull/6768 - Fixed #26751 -- Made dbshell exit with the shell's error code. https://github.com/django/django/pull/6813 - Fixed #26784 -- Made ForeignKey.validate() pass `model` to router if model_instance=None. https://github.com/django/django/pull/6806 - Fixed #26779 -- Added extra_context parameter to admin’s i18n_javascript view. https://github.com/django/django/pull/6774 - Fixed #26171 -- Made MySQL create an index on ForeignKeys with db_contraint=False. https://github.com/django/django/pull/6843 - Fixed #15091 -- Allowed passing custom encoder to JSON serializer. https://github.com/django/django/pull/6826 - Fixed #26786 -- Avoided redundant max value validators on integer fields. https://github.com/django/django/pull/6840 - Fixed #24694 -- Added support for context_processors to Jinja2 backend. https://github.com/django/django/pull/6010 - Fixed #26119 -- Fixed URLValidator crash on URLs with brackets. https://github.com/django/django/pull/6500 - Refs #23386 -- Documented that F() expressions are applied on each model.save() https://github.com/django/django/pull/6504 - Fixed #19513, #18580 -- Fixed crash on QuerySet.update() after annotate(). https://github.com/django/django/pull/6834 - Fixed #25694 -- Removed incorrect _uniq suffix on index names during migrations. https://github.com/django/django/pull/6852 - Fixed #25292 -- Fixed crash in ManyToManyField.through_fields check. https://github.com/django/django/pull/6343 - Fixed #21548 -- Added FileExtensionValidator and validate_image_file_extension. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/99207b02-cfc4-4c4d-8877-f1f9b73ceada%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Form field labels change proposal
I've talked with some other core developers at the sprint, and the proposed
flow is more in line with the initial proposal again:
* The deprecation cycle would include a settings (let's call it
CAPFIRST_MODELFORM_LABEL), defaulting to False (the new behaviour). Users
who wish to keep the old behaviour for a while set this to True
* The capfirst calls (there are 2 relevant ones) are replaced by wrappers
that check the CAPFIRST_MODELFORM_LABEL setting. If it's set to True, the
real capfirst is applied to field.verbose_name, else the raw
field.verbose_name is returned.
* The Django admin css can be updated to include the CSS rule, so it looks
still the same. Drawback is that this breaks tests if people are actively
checking the labels/HTML for forms. The recommended approach here is to
provide the capitalized strings in verbose_name
* For the front-end, the example CSS can be documented, or the option to
capitalize the verbose_name.
Note that the new behaviour would be the default in the setting.
One other drawback I just thought of is that validation errors sometimes
include the verbose_name (I think). This can look weird if the
end-developer has specified a capitalized verbose_name, but that's also the
case already. The recommended approach here would be to do the capitalizing
in CSS.
On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How would projects opt-in to the new behavior and silence the deprecation
> warning?
>
> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only apply the capfirst on ModelForm fields
>> if the model field has no explicit verbose_name set. That way, you can
>> control the capitalization on the model level without having to specify it
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter
>> so that the warning is only emited once. An example of that already exists
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be
>> handled in the djangoproject.com code, unfortunately there's no easy way
>> around that.
>>
>> This gives the developer using Django full control over the labels in a
>> DRY way.
>>
>> This approach matches Sven's latest reply.
>>
>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens
>> wrote:
>>>
>>> This is a proposal to change how Django generates form field labels from
>>> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>>
>>> This behaviour has been around since pretty much forever and makes sense.
>>>
>>> However, this affects what you put down in your translations - if a
>>> lowercased verbose name is what you want (and you translate it as such),
>>> Django will make your form labels uppercase and there's no clean way around
>>> that.
>>>
>>> There is a very specific use case for this proposal. The house-style of
>>> a design states that all form labels should be lowercase - but names of the
>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This
>>> is not easily feasible: css text-transform will also lowercase the brand
>>> name, and Django uppercases the first letter. Another possible use case
>>> could be if you insist on putting the labels to the right of the form
>>> input, but I will agree that looks silly.
>>>
>>> So the proposal is to get rid of the capfirst call, and in the admin
>>> this could be mitigated for backwards compatibility by modifying the css to
>>> include:
>>> label {
>>> text-transform: capitalize;
>>> }
>>>
>>> This is ofcourse a fairly big backwards-incompatible change towards
>>> front-end/non-vendor code, as people now have to explicitly make sure that
>>> labels are capitalized in their own templates. So this should probably go
>>> through the usual deprecation mechanics (silent, warning, remove), if it
>>> happens at all.
>>>
>>> What are current workarounds for this problem?
>>>
>>>- explicitly specifying the label value in the ModelForm definition:
>>>this violates the DRY principle, you already defined the verbose_name on
>>>the model field
>>>- creating a form mixin that will lowercase the first letter of the
>>>label for all fields
>>> - you still have to check if the first
Re: Form field labels change proposal
https://github.com/sergei-maertens/django/tree/capfirst-deprecation
contains a simple POC with the warning filtering.
On a fairly large project with a lot of ModelForms and explicit
verbose_name's, I see the warning three times on startup.
On Saturday, July 2, 2016 at 4:03:14 PM UTC+2, Sergei Maertens wrote:
>
> I am experimenting with warnings.filterwarnings('once', ...), which
> reduces the total warning output to 4 warnings, while there are about 10-15
> calls. I haven't been able to completely silence it, probably because there
> are certain imports happening before a custom filter comes into pla
>
> Opting in to the new behaviour is not covered. My personal feeling about
> this is that adding machinery to be able to opt in and silencing the
> warnings would be much more work than making the actual change. Extra
> settings were opted before, I don't like it because of the
> extra-machinery-reason I just mentioned. It *feels* as if it's either make
> the (backwards incompatible) change at once, or go through the entire
> deprecation cycle.
>
> I'm open for suggestions, since obviously I don't have all the answers
> myself...
>
> On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>>
>> How would projects opt-in to the new behavior and silence the deprecation
>> warning?
>>
>> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>>
>>> So, this is the follow up from the discussion with Markus.
>>>
>>> Implementation wise, we would only apply the capfirst on ModelForm
>>> fields if the model field has no explicit verbose_name set. That way, you
>>> can control the capitalization on the model level without having to specify
>>> it on the form again.
>>>
>>> This could go through the usual deprecation cycle, with a warnings
>>> filter so that the warning is only emited once. An example of that already
>>> exists in the migrations: django.db.migrations.state.ModelState.render:
>>> ...
>>> with warnings.catch_warnings():
>>> warnings.filterwarnings(
>>> "ignore", "Managers from concrete parents will soon
>>> qualify as default managers",
>>> RemovedInDjango20Warning)
>>> ...
>>>
>>> In our case, the 'ignore' would become 'once'.
>>>
>>> The admin CSS would be updated to include the CSS selector for labels so
>>> that the capitalization is applied in CSS.
>>>
>>> The placeholder issue for djangoproject.com would then have to be
>>> handled in the djangoproject.com code, unfortunately there's no easy
>>> way around that.
>>>
>>> This gives the developer using Django full control over the labels in a
>>> DRY way.
>>>
>>> This approach matches Sven's latest reply.
>>>
>>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens
>>> wrote:
This is a proposal to change how Django generates form field labels
from model fields. Currently, `capfirst` is called on `field.verbose_name`
(see
https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
This behaviour has been around since pretty much forever and makes sense.
However, this affects what you put down in your translations - if a
lowercased verbose name is what you want (and you translate it as such),
Django will make your form labels uppercase and there's no clean way
around
that.
There is a very specific use case for this proposal. The house-style of
a design states that all form labels should be lowercase - but names of
the
brand should be capitalized. Example: 'you agree to the Brand terms'. This
is not easily feasible: css text-transform will also lowercase the brand
name, and Django uppercases the first letter. Another possible use case
could be if you insist on putting the labels to the right of the form
input, but I will agree that looks silly.
So the proposal is to get rid of the capfirst call, and in the admin
this could be mitigated for backwards compatibility by modifying the css
to
include:
label {
text-transform: capitalize;
}
This is ofcourse a fairly big backwards-incompatible change towards
front-end/non-vendor code, as people now have to explicitly make sure that
labels are capitalized in their own templates. So this should probably go
through the usual deprecation mechanics (silent, warning, remove), if it
happens at all.
What are current workarounds for this problem?
- explicitly specifying the label value in the ModelForm
definition: this violates the DRY principle, you already defined the
verbose_name on the model field
- creating a form mixin that will lowercase the first letter of the
label for all fields
- you still have to check if the first word if it's the Brand
string, because then
Re: Form field labels change proposal
I am experimenting with warnings.filterwarnings('once', ...), which reduces
the total warning output to 4 warnings, while there are about 10-15 calls.
I haven't been able to completely silence it, probably because there are
certain imports happening before a custom filter comes into pla
Opting in to the new behaviour is not covered. My personal feeling about
this is that adding machinery to be able to opt in and silencing the
warnings would be much more work than making the actual change. Extra
settings were opted before, I don't like it because of the
extra-machinery-reason I just mentioned. It *feels* as if it's either make
the (backwards incompatible) change at once, or go through the entire
deprecation cycle.
I'm open for suggestions, since obviously I don't have all the answers
myself...
On Saturday, July 2, 2016 at 3:28:58 PM UTC+2, Tim Graham wrote:
>
> How would projects opt-in to the new behavior and silence the deprecation
> warning?
>
> On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>>
>> So, this is the follow up from the discussion with Markus.
>>
>> Implementation wise, we would only apply the capfirst on ModelForm fields
>> if the model field has no explicit verbose_name set. That way, you can
>> control the capitalization on the model level without having to specify it
>> on the form again.
>>
>> This could go through the usual deprecation cycle, with a warnings filter
>> so that the warning is only emited once. An example of that already exists
>> in the migrations: django.db.migrations.state.ModelState.render:
>> ...
>> with warnings.catch_warnings():
>> warnings.filterwarnings(
>> "ignore", "Managers from concrete parents will soon
>> qualify as default managers",
>> RemovedInDjango20Warning)
>> ...
>>
>> In our case, the 'ignore' would become 'once'.
>>
>> The admin CSS would be updated to include the CSS selector for labels so
>> that the capitalization is applied in CSS.
>>
>> The placeholder issue for djangoproject.com would then have to be
>> handled in the djangoproject.com code, unfortunately there's no easy way
>> around that.
>>
>> This gives the developer using Django full control over the labels in a
>> DRY way.
>>
>> This approach matches Sven's latest reply.
>>
>> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens
>> wrote:
>>>
>>> This is a proposal to change how Django generates form field labels from
>>> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
>>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>>
>>> This behaviour has been around since pretty much forever and makes sense.
>>>
>>> However, this affects what you put down in your translations - if a
>>> lowercased verbose name is what you want (and you translate it as such),
>>> Django will make your form labels uppercase and there's no clean way around
>>> that.
>>>
>>> There is a very specific use case for this proposal. The house-style of
>>> a design states that all form labels should be lowercase - but names of the
>>> brand should be capitalized. Example: 'you agree to the Brand terms'. This
>>> is not easily feasible: css text-transform will also lowercase the brand
>>> name, and Django uppercases the first letter. Another possible use case
>>> could be if you insist on putting the labels to the right of the form
>>> input, but I will agree that looks silly.
>>>
>>> So the proposal is to get rid of the capfirst call, and in the admin
>>> this could be mitigated for backwards compatibility by modifying the css to
>>> include:
>>> label {
>>> text-transform: capitalize;
>>> }
>>>
>>> This is ofcourse a fairly big backwards-incompatible change towards
>>> front-end/non-vendor code, as people now have to explicitly make sure that
>>> labels are capitalized in their own templates. So this should probably go
>>> through the usual deprecation mechanics (silent, warning, remove), if it
>>> happens at all.
>>>
>>> What are current workarounds for this problem?
>>>
>>>- explicitly specifying the label value in the ModelForm definition:
>>>this violates the DRY principle, you already defined the verbose_name on
>>>the model field
>>>- creating a form mixin that will lowercase the first letter of the
>>>label for all fields
>>> - you still have to check if the first word if it's the Brand
>>> string, because then it should stay capitalized
>>> - you now have to include this mixin in every single form, and
>>> can no longer rely on implicitly generated form classes in generic CBV
>>>- create a templatefilter that decapitalizes the label, and
>>>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
>>> - you now have to not forget this filter everywhere you render
>>> forms
>>> - performance hit if this
Re: Form field labels change proposal
How would projects opt-in to the new behavior and silence the deprecation
warning?
On Saturday, July 2, 2016 at 8:04:23 AM UTC-4, Sergei Maertens wrote:
>
> So, this is the follow up from the discussion with Markus.
>
> Implementation wise, we would only apply the capfirst on ModelForm fields
> if the model field has no explicit verbose_name set. That way, you can
> control the capitalization on the model level without having to specify it
> on the form again.
>
> This could go through the usual deprecation cycle, with a warnings filter
> so that the warning is only emited once. An example of that already exists
> in the migrations: django.db.migrations.state.ModelState.render:
> ...
> with warnings.catch_warnings():
> warnings.filterwarnings(
> "ignore", "Managers from concrete parents will soon
> qualify as default managers",
> RemovedInDjango20Warning)
> ...
>
> In our case, the 'ignore' would become 'once'.
>
> The admin CSS would be updated to include the CSS selector for labels so
> that the capitalization is applied in CSS.
>
> The placeholder issue for djangoproject.com would then have to be handled
> in the djangoproject.com code, unfortunately there's no easy way around
> that.
>
> This gives the developer using Django full control over the labels in a
> DRY way.
>
> This approach matches Sven's latest reply.
>
> On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens wrote:
>>
>> This is a proposal to change how Django generates form field labels from
>> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
>> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>>
>> This behaviour has been around since pretty much forever and makes sense.
>>
>> However, this affects what you put down in your translations - if a
>> lowercased verbose name is what you want (and you translate it as such),
>> Django will make your form labels uppercase and there's no clean way around
>> that.
>>
>> There is a very specific use case for this proposal. The house-style of a
>> design states that all form labels should be lowercase - but names of the
>> brand should be capitalized. Example: 'you agree to the Brand terms'. This
>> is not easily feasible: css text-transform will also lowercase the brand
>> name, and Django uppercases the first letter. Another possible use case
>> could be if you insist on putting the labels to the right of the form
>> input, but I will agree that looks silly.
>>
>> So the proposal is to get rid of the capfirst call, and in the admin this
>> could be mitigated for backwards compatibility by modifying the css to
>> include:
>> label {
>> text-transform: capitalize;
>> }
>>
>> This is ofcourse a fairly big backwards-incompatible change towards
>> front-end/non-vendor code, as people now have to explicitly make sure that
>> labels are capitalized in their own templates. So this should probably go
>> through the usual deprecation mechanics (silent, warning, remove), if it
>> happens at all.
>>
>> What are current workarounds for this problem?
>>
>>- explicitly specifying the label value in the ModelForm definition:
>>this violates the DRY principle, you already defined the verbose_name on
>>the model field
>>- creating a form mixin that will lowercase the first letter of the
>>label for all fields
>> - you still have to check if the first word if it's the Brand
>> string, because then it should stay capitalized
>> - you now have to include this mixin in every single form, and can
>> no longer rely on implicitly generated form classes in generic CBV
>>- create a templatefilter that decapitalizes the label, and
>>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
>> - you now have to not forget this filter everywhere you render
>> forms
>> - performance hit if this is based on regular expressions (which
>> in this case it is because subbrand should not become subBrand)
>>
>> All in all, I'm of the opinion that the flexibility you gain by NOT
>> manipulating the label in Django outweighs the backwards incompatible
>> change. I'm also strongly of the opinion that capitalizing labels is
>> something that should be done entirely in CSS - whether the label is
>> capitalized, lower case or upper case shouldn't matter for Django's
>> internals.
>>
>> Reasons to not do this:
>>
>>- cater to common convention, not clients (quoted from #django-dev on
>>irc): in my opinion this works 95% of the time, but your forced into
>>violating some of Django's principles if you divert from this, most
>> notably
>>DRY
>>- maintain backwards compatibility
>>
>> Reasons to do this:
>>
>>- gain flexibility about the display of form labels
>>- keep the codebase sane
>>
>>
>> Bonus: vaguely related ticket:
Re: Form field labels change proposal
This is the reworked patch assuming the deprecation process was
completed:
https://github.com/django/django/compare/master...sergei-maertens:modelform-capfirst?expand=1
On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens wrote:
>
> This is a proposal to change how Django generates form field labels from
> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>
> This behaviour has been around since pretty much forever and makes sense.
>
> However, this affects what you put down in your translations - if a
> lowercased verbose name is what you want (and you translate it as such),
> Django will make your form labels uppercase and there's no clean way around
> that.
>
> There is a very specific use case for this proposal. The house-style of a
> design states that all form labels should be lowercase - but names of the
> brand should be capitalized. Example: 'you agree to the Brand terms'. This
> is not easily feasible: css text-transform will also lowercase the brand
> name, and Django uppercases the first letter. Another possible use case
> could be if you insist on putting the labels to the right of the form
> input, but I will agree that looks silly.
>
> So the proposal is to get rid of the capfirst call, and in the admin this
> could be mitigated for backwards compatibility by modifying the css to
> include:
> label {
> text-transform: capitalize;
> }
>
> This is ofcourse a fairly big backwards-incompatible change towards
> front-end/non-vendor code, as people now have to explicitly make sure that
> labels are capitalized in their own templates. So this should probably go
> through the usual deprecation mechanics (silent, warning, remove), if it
> happens at all.
>
> What are current workarounds for this problem?
>
>- explicitly specifying the label value in the ModelForm definition:
>this violates the DRY principle, you already defined the verbose_name on
>the model field
>- creating a form mixin that will lowercase the first letter of the
>label for all fields
> - you still have to check if the first word if it's the Brand
> string, because then it should stay capitalized
> - you now have to include this mixin in every single form, and can
> no longer rely on implicitly generated form classes in generic CBV
>- create a templatefilter that decapitalizes the label, and
>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
> - you now have to not forget this filter everywhere you render forms
> - performance hit if this is based on regular expressions (which in
> this case it is because subbrand should not become subBrand)
>
> All in all, I'm of the opinion that the flexibility you gain by NOT
> manipulating the label in Django outweighs the backwards incompatible
> change. I'm also strongly of the opinion that capitalizing labels is
> something that should be done entirely in CSS - whether the label is
> capitalized, lower case or upper case shouldn't matter for Django's
> internals.
>
> Reasons to not do this:
>
>- cater to common convention, not clients (quoted from #django-dev on
>irc): in my opinion this works 95% of the time, but your forced into
>violating some of Django's principles if you divert from this, most
> notably
>DRY
>- maintain backwards compatibility
>
> Reasons to do this:
>
>- gain flexibility about the display of form labels
>- keep the codebase sane
>
>
> Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/c749d578-9464-419f-a972-a21b25ac3aec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Form field labels change proposal
So, this is the follow up from the discussion with Markus.
Implementation wise, we would only apply the capfirst on ModelForm fields
if the model field has no explicit verbose_name set. That way, you can
control the capitalization on the model level without having to specify it
on the form again.
This could go through the usual deprecation cycle, with a warnings filter
so that the warning is only emited once. An example of that already exists
in the migrations: django.db.migrations.state.ModelState.render:
...
with warnings.catch_warnings():
warnings.filterwarnings(
"ignore", "Managers from concrete parents will soon qualify
as default managers",
RemovedInDjango20Warning)
...
In our case, the 'ignore' would become 'once'.
The admin CSS would be updated to include the CSS selector for labels so
that the capitalization is applied in CSS.
The placeholder issue for djangoproject.com would then have to be handled
in the djangoproject.com code, unfortunately there's no easy way around
that.
This gives the developer using Django full control over the labels in a DRY
way.
This approach matches Sven's latest reply.
On Wednesday, November 11, 2015 at 4:59:46 PM UTC+1, Sergei Maertens wrote:
>
> This is a proposal to change how Django generates form field labels from
> model fields. Currently, `capfirst` is called on `field.verbose_name` (see
> https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L872).
>
> This behaviour has been around since pretty much forever and makes sense.
>
> However, this affects what you put down in your translations - if a
> lowercased verbose name is what you want (and you translate it as such),
> Django will make your form labels uppercase and there's no clean way around
> that.
>
> There is a very specific use case for this proposal. The house-style of a
> design states that all form labels should be lowercase - but names of the
> brand should be capitalized. Example: 'you agree to the Brand terms'. This
> is not easily feasible: css text-transform will also lowercase the brand
> name, and Django uppercases the first letter. Another possible use case
> could be if you insist on putting the labels to the right of the form
> input, but I will agree that looks silly.
>
> So the proposal is to get rid of the capfirst call, and in the admin this
> could be mitigated for backwards compatibility by modifying the css to
> include:
> label {
> text-transform: capitalize;
> }
>
> This is ofcourse a fairly big backwards-incompatible change towards
> front-end/non-vendor code, as people now have to explicitly make sure that
> labels are capitalized in their own templates. So this should probably go
> through the usual deprecation mechanics (silent, warning, remove), if it
> happens at all.
>
> What are current workarounds for this problem?
>
>- explicitly specifying the label value in the ModelForm definition:
>this violates the DRY principle, you already defined the verbose_name on
>the model field
>- creating a form mixin that will lowercase the first letter of the
>label for all fields
> - you still have to check if the first word if it's the Brand
> string, because then it should stay capitalized
> - you now have to include this mixin in every single form, and can
> no longer rely on implicitly generated form classes in generic CBV
>- create a templatefilter that decapitalizes the label, and
>re-capitalizes 'brand' occurrences to 'Brand' (currently implemented)
> - you now have to not forget this filter everywhere you render forms
> - performance hit if this is based on regular expressions (which in
> this case it is because subbrand should not become subBrand)
>
> All in all, I'm of the opinion that the flexibility you gain by NOT
> manipulating the label in Django outweighs the backwards incompatible
> change. I'm also strongly of the opinion that capitalizing labels is
> something that should be done entirely in CSS - whether the label is
> capitalized, lower case or upper case shouldn't matter for Django's
> internals.
>
> Reasons to not do this:
>
>- cater to common convention, not clients (quoted from #django-dev on
>irc): in my opinion this works 95% of the time, but your forced into
>violating some of Django's principles if you divert from this, most
> notably
>DRY
>- maintain backwards compatibility
>
> Reasons to do this:
>
>- gain flexibility about the display of form labels
>- keep the codebase sane
>
>
> Bonus: vaguely related ticket: https://code.djangoproject.com/ticket/5518
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Re: [Feature Request] Orderable ArrayAgg and StringAgg in contrib.postgres.aggregates
@Josh, thanks for pointing out the Expressions API
I will look into it and see if I can come up with a solution that looks
reasonable (including an investigation into requirements on contributing to
the GROUP BY) and report here / in Trac.
On Monday, March 7, 2016 at 1:14:06 PM UTC+1, Tim Graham wrote:
>
> Ticket for JSON_AGG: https://code.djangoproject.com/ticket/26327
>
> On Thursday, January 7, 2016 at 5:45:03 PM UTC-5, Josh Smeaton wrote:
>>
>> Seems reasonable enough to me. Expressions already support generating an
>> ORDER BY clause by calling .asc() or .desc() on them. That'd allow your
>> proposed API to support:
>>
>> Model.objects.aggregate(ArrayAgg(some_field, order_by=
>> F('some_field').asc()))
>>
>> Or any other expression. Consider that any ordering added within *may*
>> need to be contributed to GROUP BY, but I haven't read the documentation to
>> say that is a requirement.
>>
>> Feel free to open a ticket in Trac to track the feature. If you're also
>> up for implementing it (..and testing.. and documenting..) I'm quietly
>> confident that it'll be fairly straight forward to add, given familiarity
>> with Expressions API.
>>
>> Additionally, if you think json_agg and json_object_agg should be
>> implemented, you can open a feature ticket on Trac for those too.
>>
>> Regards,
>>
>> On Friday, 8 January 2016 00:46:52 UTC+11, Floris den Hengst wrote:
>>>
>>> The excellent ArrayAgg and StringAgg Postgres-specific aggregates were
>>> introduced in contrib.postgres in Django 1.9 and I've been quite happy
>>> using them here and there.
>>> Thanks for the keeping Django awesome!
>>>
>>> The documentation
>>> of
>>> Postgres 9.0 first mentions the possiblity of ordering the results within
>>> such aggregations.
>>> This could be useful in some cases.
>>> For example: it could make sense to perform the StringAgg in
>>> lexicographical order in some cases.
>>>
>>> The simple format of ordering the aggregation result in SQL is quite
>>> simple:
>>> SELECT ARRAY_AGG(some_field ORDER BY some_field ASC) FROM table;
>>> SELECT ARRAY_AGG(some_field ORDER BY some_field DESC) FROM table;
>>> SELECT ARRAY_AGG(some_field ORDER BY other_field ASC) FROM table;
>>>
>>> It would be nice if the above would be supported as follows:
>>> Model.objects.aggregate(ArrayAgg(some_field, order_by='some_field'))
>>> Model.objects.aggregate(ArrayAgg(some_field, order_by='-some_field'))
>>> Model.objects.aggregate(ArrayAgg(some_field, order_by='other_field'))
>>> where order_by is an optional parameter. If it not specified, behavior
>>> can remain unchanged from the current implementation.
>>>
>>> Note that the documentation for Postgres >= 9.3 also mentions
>>> json_agg ordering and Postgres >= 9.4 mentions json_object_agg as well.
>>> I'm unsure whether these should be included as well as I couldn't find
>>> the matching implementation in the ORM atm and have no knowledge on plans
>>> in that direction.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/5abe66e1-3ddb-41fa-86fa-f8e1007405a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
