Feature proposal: ToggleField and Toggle widget for Django Forms

Django Internals
1

Hello all!
I want to propose a new feature for handling so-called toggle buttons on the front end.

Those elements are quite common and are widely used in many frameworks, such as Bootstrap and Material UI.

Those could be narrowed down to the BooleanField but with several key differences:

  • They never be required, even if defied like so;
  • By default, they should be not required;
  • They should always return cleaned data to be False if not passed in the form data;
  • They should always have an initial value of False unless explicitly defined;
  • On invalid form data, those should not raise validation errors, but cast the value to False;
  • They have a special widget, based on the CheckboxInput, but adding role="switch"/part of the WAI-ARIA/ and aria-checked="false/true"/based on the value/. Also, maybe more controls?

The following is not that hard to achieve but is going to save a lot of time to defining such field for every project.

1 Like
2

It is common practice for proposals such as this to first be created and distributed as a third-party package. This allows for people to take a look at it and to try it, to see if it does satisfy a particular need. This also allows for some time for the code and APIs to be stabilized at a rate more appropriate for a new feature.

3

Olá, também possou esta demanda, criei algo genérico

```

ToggleSwitchWidget(size=‘sm’,     
           active_color='#9333ea',

            inactive_color='#ccc',

            active_text='Solicitada',

            inactive_text='Não Solicitada'

        ),

```
no entanto, neste caso o padrão é TRUE.
Solicita: o tamanho do Toggle, a cor de ativo, a cor de desativado, o texto de ativado e o texto de desativado.
Vamos prosseguir com a ideia?? Acredito que seria de grande valia.

4

Olá Natan, de acordo com a resposta anterior, normalmente antes de uma funcionalidade ser inserida no django é solicitada que se cria um pacote externo, que entregue essa funcionalidade, e de acordo com a tração e engajamento da comunidade no projeto com o passar dos anos, fica mais claro como esse pacote poderia ser integrado no Django, isso por que durante o desenvolvimento de uma funcionalidade como essa, sempre aparecem novos casos de uso, ou especificidades que não fazem muito sentido passar pelo desenvolvimento do django. Essa é uma política de desenvolvimento do Django: devagar e estável. Por isso o framework está há tantos anos sendo bem-sucedido. Quaisquer dúvidas, fique à vontade para entrar em contato.

In english:

Hi Natan, according to the previous answer, before a feature is added to Django, it’s usually requested that an external package to be created to deliver that functionality. As the community’s traction and engagement within the project grows over the years, it becomes clearer how this package could be integrated into Django. This is because during the development of a feature like this, new use cases or specificities always emerge that don’t make much sense to include in Django development workflow. This is a Django development policy: slow and steady. That’s why the framework has been successful for so many years. If you have any questions, feel free to contact us.