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 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/6949eabb-3dd2-4ab6-8ba9-893fb870f5a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
