Re: Form field labels change proposal

On Sat, Jul 2, 2016, Sergei Maertens wrote: >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

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

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

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

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 >

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

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

Re: Form field labels change proposal

Good evening everybody. :) I would like to reference this ticket: https://code.djangoproject.com/ticket/26497#comment:11 It appears we stumbled over this issue as well while designing a new model form. Quoting my comment from the ticket: Would it make sense to separate concepts here? 1)

Re: Form field labels change proposal

Thanks for these specific use cases, I'll see if I can come up with some acceptable solutions in a reasonable time On Apr 13, 2016 6:47 PM, "Tim Graham" wrote: > Took a quick look at djangoproject.com with this change. I noticed we're > using the label to construct an input

Re: Form field labels change proposal

Took a quick look at djangoproject.com with this change. I noticed we're using the label to construct an input placeholder [0]. I think adapting that for this change isn't so easy to do in a cross-browser way via CSS [1] but we could add capfirst in the code. The question of a deprecation

Re: Form field labels change proposal

I've done the initial work for a patch, assuming a 'hard' change without deprecation path, the branch is here: https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4. Tests should be passing. I've also taken a quick glance at django-admin-tools to check if

Re: Form field labels change proposal

It has been said before but CSS was made for this and we should not mix content with design. I'd like to see this implemented with or without the deprecation path. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django

Re: Form field labels change proposal

Looks easy enough. I was going to write, "Seems to me that there's more complexity in a deprecation path that requires a temporary opt-in setting rather than simply making the backwards incompatible change. Unless I missed something, adding CSS like that shouldn't cause problems for any apps

Re: Form field labels change proposal

In https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31, after label { font-weight: normal; color:#666; font-size:13px; } you would add label::first-letter { text-transform: capitalize; } (see

Re: Form field labels change proposal

I'd like to see the admin's CSS updated under the assumption that this change moves forward to better understand the extent of changes that would be required from Django users to maintain the current behavior. On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote: > > Yes,

Re: Form field labels change proposal

Yes, I've thought about a setting as well briefly but quickly discarded it because it would be 'yet another setting'. But this one would ofcourse be temporarily, and if that's been applied successfully in the past, then that's probably the best way to tackle this. I'd be happy to write the

Re: Form field labels change proposal

The best solution I can think of at the moment would be a setting allowing users to opt-in to the new behavior which would then silence the warning. That leaves you with a defunct setting once the deprecation period completes. That's basically how SessionAuthenticationMiddleware worked when we

Re: Form field labels change proposal

Good catch. I'm not sure, haven't there been similar cases in the past? First thing I can think of is using naive datetimes when timezone-support is enabled, and then you get a warning for each naive datetime you use, but that's of course different then a DeprecationWarning. It's probably not

Re: Form field labels change proposal

How would a developer acknowledge/silence that deprecation warning? It seems to me that if it's emitted for every form field in a project that's not really going to be helpful. On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens wrote: > > I think I would start with locally

Re: Form field labels change proposal

I’ve always been annoyed by having to define lower case model field labels and capitalized form field labels. Inconsistencies always creep in. I would like to see this suggestion implemented, if we can provide a decent upgrade story for Django users. -- Aymeric. > On 11 nov. 2015, at

Re: Form field labels change proposal

I really don't like text-styling functions in Django that are (even indirectly) used in templates. CSS was made for this. The solution Sergei proposed smoothly transitions the admin. However, alot of forms will be affected as well and thus alot of users. The deprecation warning Sergei proposes

Re: Form field labels change proposal

I think I would start with locally creating a wrapper capfirst that is only called in the referenced line and https://github.com/django/django/blob/master/django/db/models/fields/__init__.py#L2069 (missed that one in the previous post) and possible other ocurrences. Emit a

Re: Form field labels change proposal

How do you envision putting this through a deprecation cycle? On Wednesday, November 11, 2015 at 10:59:46 AM UTC-5, 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 >

Form field labels change proposal

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