En utilisant le tag dsfr_card, le lien n'est pas dans le HTML généré.

Exemple d'utilisation :

{% dsfr_card title=subblock.value.title description=subblock.value.description link=subblock.value.url image_url=img.url %}

Dans le code généré, le href est vide :
<a href="" target="_self">

D'après un commentaire de @christophehenry sur #83 :

Ok, je comprends le problème. Ça vient de la façon de mélanger les ModelForm et DsfrBaseForm. ModelForm.default_renderer() prend le pas sur DsfrBaseForm.default_renderer().

Selon moi, il faudrait déprécier cette méthode en faveur d'un DsfrModelForm dans une version majeure, ce qui crérait moins de risque d'erreur avec la résolution des ancêtres.

Mais si cette solution est écartée, il faudrait au moins remplacer:

TEMPLATES = [
    {
        [...]
        "DIRS": [
            os.path.join(BASE_DIR, "dsfr/templates"),
            os.path.join(BASE_DIR, "templates"),
        ],
    },
]

par :

INSTALLED_APPS = [
    ...
    "widget_tweaks"
    "dsfr",
    "django.forms",
    <votre_app>
]

dans la documentation pour se rendre conforme avec la documentation Django.

Concernant, le tag {% dsfr_form_field %}, lorsqu'une case à cocher est présentée seule, elle est affichée avant le libellé, conformément au DSFR. Cependant, dans ce contexte, les ":" (deux points) qui suivent habituellement le libellé sont quand même affichés après le libellé, ce qui peut sembler incohérent. Pour rendre l'interface plus logique et cohérente, il serait préférable de ne pas afficher les ":" lorsque le type d'input est une case à cocher. Ainsi, cela correspondrait mieux à l'affichage de la case à cocher avant le libellé.

Ce qui est affiché actuellement :

<div class="fr-checkbox-group">
    <input type="checkbox" name="sample_boolean" id="id_sample_boolean" />
    <label for="id_sample_boolean" class="fr-label">
        <label for="id_sample_boolean">Cochez la case&nbsp;:</label>
    </label>
</div>

Ce qui devrait être idéalement affiché :

<div class="fr-checkbox-group">
    <input type="checkbox" name="sample_boolean" id="id_sample_boolean" />
    <label for="id_sample_boolean" class="fr-label">
        <label for="id_sample_boolean">Cochez la case</label>
    </label>
</div>

Django-DSFR peut être utilisé sur des sites en d'autres langues que le français. Il faut que les textes affichés soient traduits au moins en anglais et dans une 3e langue, en vertu de la loi n° 94-665 du 4 août 1994 relative à l'emploi de la langue française, et conformément à la politique gouvernementale constante en faveur du plurilinguisme.

La librairie react-dsfr a une traduction partielle apparemment (cf. footer)

Hello,

Currently it is not possible to add a name to a button.
I suggest to add this possibility, thus the dictionary for the button would look like that :

BTN_SUBMIT = {
        "label": "Soumettre",
        "onclick": "",
        "type":"submit",
        "extra_classes": ".........",
        "name": ".........",
    }

Is it possible ? Should I make a pull request ?

Thank you !

Il faudrait :

• Ajouter un champ pour le code langue, et faire en sort qu'il n'y ait qu'une DsfrConfig par code langue
• Faire en sorte que le context_processor renvoie la configuration dans la langue sélectionnée si elle existe, ou, à défaut, la première.

La documentation indique :

Django-DSFR (partly) implements the version 1.9.2 of the DSFR.

Il ne me semble pas que ce qui n'est pas implémenté soit documenté.

Les boutons radio riches sont un champ avancé qui n'a pas d'équivalent direct dans Django. Il faudrait cependant pouvoir les gérer dans Django-DSFR autrement qu'en construisant le formulaire à la main.

• Documentation des boutons radio dans Django

Les boutons radio peuvent être rendus inline dans le DSFR. Le template actuel ne le permet pas.

J'ai pas de vraie solution pour le moment. Peut-être juste un widget InlineRadioSelect, mais ça veut dire qu'il faudrait faire ça pour chaque ChoiceWidget (y'en a un paquet).

Hi, I was thinking of moving this repo elsewhere to make easier adding new contributors that are not currently members of EIG. Not sure where though. Betagouv? Its own org?

Il y a un défaut d’architecturalement que j'estime important. Le code pour l'exécution normale de l'application se trouve trop dans le dossier example_app. Ceci pose un problème important d'unifomalité et d'automatismes de transpositions / traductions (traductions au sens propre).

Faisons en sorte que DSFR (devrait-il être django_dsfr au fait, y compris dans templates et static ?) reprennent le code de example_app qui n'a pas besoin d'être dans example APP. Je pense par exemple à Search.

Cf. notes de version de la version 1.10.0 du DSFR :

✨ Tuile : plusieurs variations sur deux tailles, SM et MD avec le rajout d’une icône optionnelle, par défaut une flèche.

✨ Téléchargement de fichier :

🎉 Nouvelle variation disponible : Tuile de téléchargement
✨ Évolution de la variation Carte anciennement appelé “Bloc de téléchargement” avec la possibilité d’y inclure un média au ratio 3:4 ou 4:3 et de pouvoir afficher des tags ou badges.

La version actuelle du DSFR est 1.10.1. La version embarquée dans django-dsfr est 1.9.2 soit 3 versions de retard. Il serait bien aussi de documenter ce qu'il faut faire lors de la mise à jour d'une nouvelle version du DSFR. De ce que j'ai vu dans le code, il ne suffit pas de bouger le dist du DSFR dans dsfr/static/dsfr/dist. J'ai l'impression qu'il faut aussi mettre les les hash d'intégrité à jour et faire tourner la commande trim_dist ?

Bonjour,

Le champ checkbox a un problème, il affiche 2 fois le libellé et le helptext du champ. Une fois avant les checkboxes, une fois après, comme ceci :

Ce bug est notamment visible sur l'application de test (d'où vient cette capture d'écran) : https://numerique-gouv.github.io/django-dsfr/form/example/

Cordialement.

Déclenche l'erreur

ModuleNotFoundError: No module named 'widget_tweaksdsfr'

car il manque une virgule dans la liste des INSTALLED_APPS.

Liste des composants demandés dans le cadre de la refonte de numerique.gouv.fr (à créer complètement, ou du moins ajouter les options manquantes)

• Badge
• Carte
• Citation
• Contenu média
• Header
• Fil d'ariane
• Gestionnaire de consentement
• Lettre d'information et Réseaux Sociaux (follow)
• Lien
• Menu latéral (side menu)
• Mise en avant : développer toutes les mises en avant
• Mises en exergue
• Navigation principale
• Onglets
• Partage
• Tag
• Téléchargement de fichier : carte de téléchargement + lien de téléchargement
• Transcription
• Champ de saisie  (pour les inscriptions notamment)

Django 4.0 a introduit l'API Form rendering qui rend {% dsfr_form %} obselète. Je propose de modifier {% dsfr_form %} pour lever une notice de dépreciation à partir de Django 4.0+ et supprimer le support dans la prochaine majeure et supprimer totalement la balise quand il sera décidé de laisser tomber le support de Django<4.0.

Les curseurs sont un champ avancé qui n'a pas d'équivalent direct dans Django. Il faudrait cependant pouvoir les gérer dans Django-DSFR autrement qu'en construisant le formulaire à la main.

(à faire en rentrant de vacances en août)

La version 1.12 du design system est sortie. https://www.systeme-de-design.gouv.fr/a-propos/versions/version-courante

Pourquoi ne pas positionner la documentation (actuellement example_app si j'ai bien compris) dans le répertoire doc qui sert à ça d'habitude ?

TemplateDoesNotExist on admin login

What happened ?

Created a superuser. Upon trying to reach /admin/login/?next=/admin/, I get :

I'm working on Django-template with python 3.9.6, Django==4.1.7 and django-dsfr==0.12.0 (same issue with 0.14.0)

Commenting FORM_RENDERER = "django.forms.renderers.TemplatesSetting" in settings allows me to reach the page.

L'URL du site du gouvernement a changé, il faut mettre le pied de page à jour.

Note : ce changement n'est pas encore reflété dans la documentation officielle du SIG.

(à faire en rentrant de vacances en août)

Le support de Django 3.2 LTS s'est achevé en avril, il faut donc le retirer des versions supportées dans le README.rst, le pyproject.toml et la CI.

Django 4+ supporte uniquement Python 3.10+, il faut donc aussi retirer le support des versions 3.8 et 3.9 de Python.

Hello,

I had to make forms with django-dsfr and I encountered several difficulties to make them. Indeed {{ form.as_p }} didn't render the form with the dsfr, and {% dsfr_input ... %} meant that we had to create each field separately without using a form class in forms.py.

I worked on a form_base.html file that could be useful to everyone to work more easily on forms with django-dsfr. It is a file that extends your base.html and is used by extending it in your form templates.
This file require a dependency : widget-tweaks. I suggest that it is added in django-dsfr.
I have also modified the widget templates : checkbox_option.html, input_option.html, multiple_input.html and radio_option.html.

Using these, it is possible to create a form class in forms.py, use it in a view class, and your form template would just look like this :

{% load static dsfr_tags %}

{% block head-form %}
    <h2>Test de formulaire</h2>
{% endblock head-form %}

{% block foot-form %}
    {% dsfr_button btn_submit %}
{% endblock foot-form %}

Let me know if it's ok with you to pull a request ?
Thank you

Bonjour,

Je rencontre un problème au niveau des dsfr_alert. Après avoir bien fouillé avec des collègues, nous pensons (sans être sûrs) que le problème vient d'une boucle javascript quelque part qui aurait une erreur.

Le problème : lorsque je mets un {% dsfr_alert foo %} dans un template, l'alerte ne s'affiche pas. Pourtant elle existe bien, elle est présente dans le code html de la page, mais il manque à la div du message la classe "fr-collapse--expanded" ainsi que "style="--collapse-max-height: none; --collapse: -44px;". En rajoutant à la main dans l'inspecteur cette classe et ce style dans la div, le message s'affiche bien.
Mon html :

Le rendu sur la page : rien

Ce que je vois dans l'inspecteur :

(l'alerte existe mais elle ne s'affiche pas)

En rajoutant à la main ce qu'il faut :

Le rendu sur la page :

(l'alerte s'affiche désormais).

Plus étrange encore : Si je mets DEUX FOIS mon alerte, comme ceci :

(Deux fois exactement la même)

Le rendu :

(L'alerte n'apparait qu'une seule fois)

Ce qu'on voit sur l'inspecteur :

Les deux alertes existent dans le code, mais seule la première a reçu la classe fr-collapse--expanded et le style qui convient, pas la deuxième.

C'est ce qui nous fait penser qu'il doit y avoir une boucle quelque part qui ajoute la classe fr-collapse--expanded à toutes les div de message, mais avec une erreur de type commencer à 1 plutôt que 0.

Savez-vous ce qui peut causer ça ? Rencontrez-vous le même problème ?

A savoir que j'utilisais une ancienne version de django-dsfr (0.11.1) et mon code marchait sans problème en ne mettant qu'une seule fois {% dsfr_alert message.message|to_dict %}. C'est depuis que j'ai fait la mise à jour vers django-dsfr 0.16.2 que j'ai ce bug.
J'espère que ma description du problème est claire, ce n'est pas facile à expliquer.

Je vous remercie,

Cordialement.

Certains composants ne gèrent pas toutes les personnalisations autorisées par la documentation officielle (notamment les couleurs)

A minima (liste à compléter)

• Citation (quote)
• Mise en avant (callout)
• Mise en exergue(highlight)
• Sommaire (summary) - gestion de la balise pour le titre "Sommaire" (<p> ou <hx>)
• Carte (card) : autoriser les cartes sans lien
• Tuile (tile) : autoriser les cartes sans lien

At the moment, Django 3.2.x and Django 4.0.x are supported by the Django project. It would be nice to be able to use django-dsfr with Django 4.0.x.

Happy to try and submit a PR but I'm not yet sure how to change pyproject.toml and the github action to make sure the CI tests both branches.

Les contrôles segmentés sont un champ avancé qui n'a pas d'équivalent direct dans Django. Il faudrait cependant pouvoir les gérer dans Django-DSFR autrement qu'en construisant le formulaire à la main.

Le design du DSFR permet d'introduire des informations supplémentaires sous un champs, comme pour le champ mot de passe sur ce formulaire. Malheureusement, Field ne fourni aucun paramètre qui permette d'avoir ces infos.

3 solutions possibles :

1. documenter un champ Field.additionnal_field_infos à utiliser comme suit :

   class ExampleForm(DsfrBaseForm):
       field = TextInput()
   
       def __init__(self, *args, **kwargs):
           super().__init__(*args, **kwargs)
           self["field"].additionnal_field_infos = mark_safe(
               '<p class="fr-message fr-message--info">12 caractères minimum</p>'
           )

2. utiliser form.field[""].widget.attr :

   class ExampleForm(DsfrBaseForm):
       field = TextInput(widget=Widget(attrs={
           "additionnal_field_infos": mark_safe(
               '<p class="fr-message fr-message--info">12 caractères minimum</p>'
           )
       })) 
   
       def __init__(self, *args, **kwargs):
          # Ou alors
           self["field"].widget.attrs["additionnal_field_infos"] = mark_safe(
               '<p class="fr-message fr-message--info">12 caractères minimum</p>'
           )
           super().__init__(*args, **kwargs)

3. déclarer un membre additionnal_field_infos pour la classe DsfrBaseForm qui s'utiliserait comme suit :

     class ExampleForm(DsfrBaseForm):
       field = TextInput()
       additionnal_field_infos = {
           "field": mark_safe(
               '<p class="fr-message fr-message--info">12 caractères minimum</p>'
           )
       }

Aucune solution n'est vraiment satisfaisante.

1. oblige à toujours écrire un __init__ et peut être incompréhensible si la personne écrit self["field"] (qui contient le Field) au lieu de self.fields["field"] (qui contient le BoundField correspondant).

2. mélange des informations sur les attributs HTML avec des informations sur le widget, ce qui est contre-intuitif, oblige à surcharger le paramètre widget du Field ou écrire un __init__.

3. a ma préférence, même si elle n'est pas très Djangonique. L'idéal serait un membre dans la classe Meta mais seule ModelForm a une classe Meta.

utility.min.css contient des classes CSS intéressantes comme .fr-background-default--grey.