Re: What to do about formfield_callback?

[Carlton Gibson]

Hey James,

Yes, I’ll top-post because I basically agree with all of that. Thanks.
+1

C.

> On 6 Jun 2021, at 01:34, James Bennett  wrote:
> 
> On Fri, Jun 4, 2021 at 11:54 PM Carlton Gibson  
> wrote:
>> I'm sympathetic to the suggestion here, but wary of expanding the Forms API, 
>> which already has a number of different ways of holding it.
>> 
>>> ...to impose uniform custom widget attributes and error messages across a 
>>> bunch of ModelForms...
>> 
>> My initial query is, would not defining `field_classes`[1] on, say, a base 
>> form class for your project be a/the way to go here?
> 
> Without getting too far off into details, the basic issue is I have an
> app where there are a lot of ModelForms, and for certain model field
> types we want the form field to always get set up in a way that
> differs from Django's defaults (think of, say, always wanting a
> particular custom widget setup, or custom error messages, for a
> particular model field type).
> 
> It's a thing that you *can* do by writing out overrides or
> re-declarations of the relevant fields on each form. But when you have
> dozens of forms and there's no consistent pattern to the naming of the
> fields you want to override, it gets really tedious to write out and
> maintain all those overrides.
> 
> Which is why the code uses formfield_callback -- that is Django's
> customization hook for this type of "every instance of model field of
> this type, output a form field of this type" stuff. And it's already
> crept into documented API, to some extent, because the model
> form/formset factories document it as a parameter.
> 
> So I'd just like for it to become proper fully-documented API with
> consistent behavior (since right now its behavior and effect varies
> according to how you specify it and how you construct your forms).
> 
> (the only other real alternative right now is to go write a custom
> model field subclass and implement formfield() on it, then go migrate
> a bunch of models to use the new custom field instead of the default
> Django one. But it feels odd and wrong to me that form-only behavior
> would need to be overridden in the model rather than in the form)
> 
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAL13Cg8thHw7Sj-8KoAzU4J0QgWo9EXMNXDw1jkt2QtZBvDf5g%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CC2064DE-79CD-480D-A370-322F1D6766BB%40gmail.com.


signature.asc
Description: Message signed with OpenPGP

Re: Changing widget rendering templates

[smi...@gmail.com]

Hi All,

Thanks for your repsonses and guidance.

I think for the widget changes we have far less flexibility than with forms 
where folk are already using various as_* functions. I'll therefore 
progress with the widget ticket as a breaking change. 

For the form changes I think it makes sense to make the existing as_* forms 
as accessible as we can. We can also intoduce a new template that is a 
"best practice" implementation. Making this the defualt while breaking 
wouldn't be too hard for folk to adjust as they would just use `as_table`.

Hopefully I've understood this correctly.

Thibaud -- just a few comments on your email. 

> widgets’ rendering to fix:

Looking at the ticket, I think these would require changes to the form 
render rather than the widget. Once we have the template rendering of forms 
PR merged, I think these will be easier to implement. 

>  Or provide alternative forms you might already be aware of,

The test project for crispy-forms has a django rendered page, this could be 
of help? https://github.com/django-crispy-forms/crispy-test-project 

> showcasing more advanced widget configurations

Looking at your page I think the couple of additional items which would be 
useful to get your views on would be:

- A grouped input (rendered with select, checkbox and radio widgets). I am 
not sure "grouped input" is the right terminology, I'm trying to expain the 
`MEDIA_CHOICES` example as shown 
here. 
https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.choices

- A multifield/multiwidget. `SplitDateTimeField` is a good example. 
Personally, I've found this one troublesome 
(https://forum.djangoproject.com/t/accessibility-for-splitdatetimefield/6871)

Kind Regards

David

On Sunday, 6 June 2021 at 01:22:19 UTC+1 Thibaud Colas wrote:

> Hi all,
>
> I wanted to mention a couple more things that might help in the decision:
>
>
>- There is no direct accessibility issue *for end users* from `as_p` 
>that I know of. The only issue is its propensity to making people create 
>forms with invalid HTML (see #31189 
>), which is problematic 
>when running HTML validation, and is a failure of WCAG 2.1 level A SC 
>4.1.1 Parsing 
> (this 
>standard being the most likely target for Django, although there is no 
>official target as of now).
>- I’ve just opened two tickets that, if confirmed, would require 
>additional changes to the widgets’ rendering to fix: #32819 
>, #32820 
>.
>
> I imagine we want to release changes to forms’ rendering as infrequently 
> as possible. If we considered grouping those changes all in the same 
> release, it could be worthwhile for me to further review forms and fields 
> for any further issues there might be, so they can be fixed at the same 
> time. One problem I’m facing with this and similar audits is that I almost 
> never use Django’s default markup myself, so it would be nice for others to 
> look at the form I’m using for testing (code 
> 
> , rendering 
> ) and 
> confirm it’s suitable. Or provide alternative forms you might already be 
> aware of, set up differently or showcasing more advanced widget 
> configurations.
>
> Those additional tickets reflect the extent of my audit progress to date. 
> One thing I’m considering but am uncertain of is whether non-field errors 
> would also need ARIA markup, to be more identifiable as errors, and-or 
> programmatically associated with the form. I still need to research this, 
> both according to specs, and with actual support from screen readers.
>
> Kind regards,
>
> Thibaud
>
> On Saturday, 5 June 2021 at 09:31:54 UTC+1 Adam Johnson wrote:
>
>> I think a breaking change for the widget HTML is fine too, if it improves 
>> everyone’s apps. Perhaps documenting in the release notes how to undo it 
>> (eg copy this template file into your project, reconfigure the widget to 
>> use the template like so) will make it easier for folks with incompatible 
>> CSS to upgrade.
>>
>> On Sat, 5 Jun 2021 at 08:45, Carlton Gibson  wrote:
>>
>>> Hi David. 
>>>
>>> Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)
>>>
>>> I'd say option 1: It's an accessibility change and we should just opt 
>>> people into that. IIRC there are some small improvements to the current 
>>> HTML (aria roles and such) that would improve accessibility even if not 
>>> perfectly. We should add those. (Folks can revert to the old templates if 
>>> they must, assuming we note the changes.)
>>>
>>> With the template based rendering in place, I'd think (though) we could 
>>> eventually

Re: Changing widget rendering templates

[Tom Carrick]

I agree with everything said here so far.

I just want to add that I wonder if it is perhaps a good idea to deprecate
and dedocument as_p and friends, but leave them in the code base for
existing projects?

Tom

On Sun, 6 Jun 2021, 09:25 smi...@gmail.com,  wrote:

> Hi All,
>
> Thanks for your repsonses and guidance.
>
> I think for the widget changes we have far less flexibility than with
> forms where folk are already using various as_* functions. I'll therefore
> progress with the widget ticket as a breaking change.
>
> For the form changes I think it makes sense to make the existing as_*
> forms as accessible as we can. We can also intoduce a new template that is
> a "best practice" implementation. Making this the defualt while breaking
> wouldn't be too hard for folk to adjust as they would just use `as_table`.
>
> Hopefully I've understood this correctly.
>
> Thibaud -- just a few comments on your email.
>
> > widgets’ rendering to fix:
>
> Looking at the ticket, I think these would require changes to the form
> render rather than the widget. Once we have the template rendering of forms
> PR merged, I think these will be easier to implement.
>
> >  Or provide alternative forms you might already be aware of,
>
> The test project for crispy-forms has a django rendered page, this could
> be of help? https://github.com/django-crispy-forms/crispy-test-project
>
> > showcasing more advanced widget configurations
>
> Looking at your page I think the couple of additional items which would be
> useful to get your views on would be:
>
> - A grouped input (rendered with select, checkbox and radio widgets). I am
> not sure "grouped input" is the right terminology, I'm trying to expain the
> `MEDIA_CHOICES` example as shown here.
> https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.choices
>
> - A multifield/multiwidget. `SplitDateTimeField` is a good example.
> Personally, I've found this one troublesome (
> https://forum.djangoproject.com/t/accessibility-for-splitdatetimefield/6871
> )
>
> Kind Regards
>
> David
>
> On Sunday, 6 June 2021 at 01:22:19 UTC+1 Thibaud Colas wrote:
>
>> Hi all,
>>
>> I wanted to mention a couple more things that might help in the decision:
>>
>>
>>- There is no direct accessibility issue *for end users* from `as_p`
>>that I know of. The only issue is its propensity to making people create
>>forms with invalid HTML (see #31189
>>), which is problematic
>>when running HTML validation, and is a failure of WCAG 2.1 level A SC
>>4.1.1 Parsing
>> (this
>>standard being the most likely target for Django, although there is no
>>official target as of now).
>>- I’ve just opened two tickets that, if confirmed, would require
>>additional changes to the widgets’ rendering to fix: #32819
>>, #32820
>>.
>>
>> I imagine we want to release changes to forms’ rendering as infrequently
>> as possible. If we considered grouping those changes all in the same
>> release, it could be worthwhile for me to further review forms and fields
>> for any further issues there might be, so they can be fixed at the same
>> time. One problem I’m facing with this and similar audits is that I almost
>> never use Django’s default markup myself, so it would be nice for others to
>> look at the form I’m using for testing (code
>> 
>> , rendering
>> ) and
>> confirm it’s suitable. Or provide alternative forms you might already be
>> aware of, set up differently or showcasing more advanced widget
>> configurations.
>>
>> Those additional tickets reflect the extent of my audit progress to date.
>> One thing I’m considering but am uncertain of is whether non-field errors
>> would also need ARIA markup, to be more identifiable as errors, and-or
>> programmatically associated with the form. I still need to research this,
>> both according to specs, and with actual support from screen readers.
>>
>> Kind regards,
>>
>> Thibaud
>>
>> On Saturday, 5 June 2021 at 09:31:54 UTC+1 Adam Johnson wrote:
>>
>>> I think a breaking change for the widget HTML is fine too, if it
>>> improves everyone’s apps. Perhaps documenting in the release notes how to
>>> undo it (eg copy this template file into your project, reconfigure the
>>> widget to use the template like so) will make it easier for folks with
>>> incompatible CSS to upgrade.
>>>
>>> On Sat, 5 Jun 2021 at 08:45, Carlton Gibson 
>>> wrote:
>>>
 Hi David.

 Thanks for this. Sorry for the slow pick-up: DjangoCon this week. :)

 I'd say option 1: It's an accessibility change and we should just opt
 people int

Checking logs of a Jenkins CI job

[Sanskar Jaiswal]

Hello everyone

I'm working on this PR 
(https://link.getmailspring.com/link/c4c0c208-5094-4f28-a50b-cad7854e5...@getmailspring.com/0?redirect=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fpull%2F13559&recipient=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)
 which didn't pass the CI checks (which is weird as all tests pass on my 
machine) and I could not check the logs instantly due to some issues with my 
laptop. Jenkins gives a 404 when I try to check the logs now, which leads me to 
believe that they've been removed. Is there anyway to check the logs now or 
should I make a dummy commit to trigger the jobs again? Thank you for your help 
:)
Cheers
Sanskar

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/C4C0C208-5094-4F28-A50B-CAD7854E582F%40getmailspring.com.

django projects in india

[Cyber Black]

hey, i am tushar chauhan from india in dehradun so i hope everyone are good 
i want to discuss for django scope in india i want to say i have completed 
django framework and some projects like instagram faceboook youtube and crm 
, csm , mlm , cms and more but i am unable to finding project for works 
means(money source) so if you have anymarket where i can make project for 
eran money so plz tell me.. 
thanks a lot.. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6d009740-1a98-41a3-80c3-28102231c02an%40googlegroups.com.

Re: Checking logs of a Jenkins CI job

['Adam Johnson' via Django developers (Contributions to Django itself)]

The logs last a limited amount of time, I think it’s maybe 7 days. You’ll
need to push again to trigger a new run after that.

On Sun, 6 Jun 2021 at 12:57, Sanskar Jaiswal 
wrote:

> Hello everyone
>
>  I'm working on this PR
> 
>  which
> didn't pass the CI checks (which is weird as all tests pass on my machine)
> and I could not check the logs instantly due to some issues with my laptop.
> Jenkins gives a 404 when I try to check the logs now, which leads me to
> believe that they've been removed. Is there anyway to check the logs now or
> should I make a dummy commit to trigger the jobs again? Thank you for your
> help :)
>
> Cheers
> Sanskar
> [image: Sent from Mailspring]
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/C4C0C208-5094-4F28-A50B-CAD7854E582F%40getmailspring.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3nWmMWiwuQhC3c1tMxOVJ5L0VvDOFSP3LZhwsFPubNJw%40mail.gmail.com.

Re: django projects in india

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi

This mailing list is not for commercial purposes.

Thanks,

Adam

On Sun, 6 Jun 2021 at 08:31, Cyber Black 
wrote:

> hey, i am tushar chauhan from india in dehradun so i hope everyone are
> good i want to discuss for django scope in india i want to say i have
> completed django framework and some projects like instagram faceboook
> youtube and crm , csm , mlm , cms and more but i am unable to finding
> project for works means(money source) so if you have anymarket where i can
> make project for eran money so plz tell me..
> thanks a lot..
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/6d009740-1a98-41a3-80c3-28102231c02an%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2cGua0NPz2n6JEvq-MZQLJ1HC2-Ndfqv-NsJZRGupj7w%40mail.gmail.com.

Do we add versionadded blocks or does the release manager?

[Jared Chung]

If I'm contributing a new feature, would it be appropriate for my PR to 
include the `versionadded` block in the documentation (using the current 
"in-development" version number which as of today is 4.0), or is managing 
the `versionadded` block something that the release manager does? Thanks in 
advance. 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d37d81e-e359-47b7-9ba4-758664923e94n%40googlegroups.com.

Re: Do we add versionadded blocks or does the release manager?

[Carlton Gibson]

Hi Jared,

It’s great if you add them.
The eventual merger will review them, but it’s good to have them in place from 
the beginning.

Thanks!

Kind Regards,

Carlton


> On 7 Jun 2021, at 07:11, Jared Chung  wrote:
> 
> If I'm contributing a new feature, would it be appropriate for my PR to 
> include the `versionadded` block in the documentation (using the current 
> "in-development" version number which as of today is 4.0), or is managing the 
> `versionadded` block something that the release manager does? Thanks in 
> advance.
> 
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3d37d81e-e359-47b7-9ba4-758664923e94n%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EBC3F1E7-D716-42C6-B60E-B91FAC8F58B8%40gmail.com.


signature.asc
Description: Message signed with OpenPGP