Django : un modèle sur mesure : DaysField étape 2/3

Formulaire spécifique pour un modèle sur-mesure

Après les conversions (base / et / ou / Python) vers données Python (dans les deux sens), il nous faut écrire notre formulaire spécifique pour notre modèle DaysField sur-mesure.

Ici, l’utilisateur doit pouvoir cocher / ou pas / des valeurs qui correspondent aux jours de la semaine.

Au jour de l’écriture de ce document, la documentation n’est pas complète.
Officiellement, il « suffirait » de surcharger def formfield(self, **kwargs) en y ajoutant sa propre classe de formulaire via l’index « form_class » de kwargs.

L’exemple proposé ne fonctionne pas !

En effet, lorsqu’on affiche le modèle dans l’interface d’administration, kwargs est déjà pré-rempli avec l’indice « widget » qui est le composant spécifique pour l’administration. Pour que leur exemple fonctionne, il faudrait supprimer « widget » avant d’y ajouter « form_class ».

J’ai opté pour la méthode directe qui ignore « kwargs » :
    def formfield(self, **kwargs):
        # ignore the admin directives: directly override with our custom form:
        return super().formfield(form_class=DaysFormField,
                                 initial=[])

Enfin, la classe DaysFormField elle-même :
class DaysFormField(forms.TypedMultipleChoiceField):
    def __init__(self, *args, **kwargs):
        if 'max_length' in kwargs:
            kwargs.pop('max_length')
        kwargs['choices'] = DaysOfWeek.CHOICES
        super().__init__(*args, **kwargs)

Cela affiche maintenant un choix ainsi :
Custom field DaysField choice 1.jpg

On peut facilement le modifier en y précisant un autre widget, par exemple :
class DaysFormField(forms.TypedMultipleChoiceField):
    widget = forms.CheckboxSelectMultiple
    # (le reste du code avec __init_())

Cela affiche maintenant un choix ainsi :
Custom field DaysField choice 2.jpg

Django : un modèle sur mesure : DaysField étape 1/3

Le principe

Je voulais un modèle de données qui stocke les jours d’une semaine que l’utilisateur désire, et qui les stocke sous forme de chaîne simple, avec des numéros qui correspondent aux jours de la semaine.
J’ai appelé ce modèle DaysField.
Les valeurs sont stockées par rapport aux jours choisis. Par exemple, 1,3 signifie que l’utilisateur a choisi lundi et mercredi parmi les jours. 6,7 correspondent à samedi et dimanche. Pour finir, tous les jours de la semaine cochés serait donc : 1,2,3,4,5,6,7

Toujours descendre d’un modèle classique

J’ai retenu ces principes et cela semble suffire pour fonctionner : on descend du modèle qu’on veut écrire en base de données. Ici, je voulais écrire une chaîne de caractères dans la base ⇒ on descend de CharField(), en modifiant la description au passage :
class DaysField(models.CharField):
    description = _("Comma-separated integers between 1 and 7")

Conversion de « sources » différentes en données Python

Pour résumer : les modèles ont deux « arrivées » de données :

  • quand on les données viennent de la base = from_db_value() ;
  • quand on les données viennent d’un formulaire (ou autre, mais en gros quand ça vient pas de la base de données mais du code Python lui-même) = to_python().

Il faut donc gérer ces deux cas, qui, dans les deux cas, doivent renvoyer quelque chose au format Python qui nous intéresse.
Ici, c’est un tableau d’entiers compris entre 1 et 7 qui correspond aux jours de la semaine.

J’ai centralisé la gestion des deux « arrivées » (base et Python) dans une seule fonction : value_to_array() :

    @staticmethod
    def value_to_array(value):
        if value is None:
            return None
        try:
            if isinstance(value, list):
                return [int(a) for a in value]
            elif isinstance(value, str):
                return [int(a) for a in value.split(',')]
        except (TypeError, ValueError):
            raise ValidationError(_("Unexpected value"))
        raise ValidationError(_("Unexpected value"))
    @staticmethod
    def from_db_value(value, expression, connection):
        return DaysField.value_to_array(value)
    def to_python(self, value):
        return DaysField.value_to_array(value)

Peut-être existe-t-il des cas où la provenance du code Python doit être gérée différemment de la provenance de la base de données… ici ce n’est pas le cas – et si vous avez des exemples de gestion différentes pour des entrées de base et de code, laissez-moi un commentaire, car je n’en vois pas…

Conversion de données Python ⇒ données pour la base

C’est la fonction get_prep_value().

Dans le cas DaysField, c’est très simple :
    def get_prep_value(self, value):
        return ','.join([str(a) for a in value]) \
            if value is not None else None

On prend toutes les valeurs du tableau, on les concatène avec la virgule , comme séparateur. C’est plus long de l’expliquer que de le coder !

Django rest framework : Got AttributeError when attempting to get a value for field `my_field` on serializer `UserSerializer`.

Si vous voulez faire un mapping avec un modèle c’est ultra simple. Si vous voulez ajouter un champ custom, là ça devient compliqué…

Aucune réponse viable sur stackoverflow, vous risquez de chercher longtemps.

Si vous avez fait un code comme cela, pour rajouter un champ « custom » :

class UserSerializer(serializers.ModelSerializer):
    my_field = serializers.CharField(allow_blank=True)
    class Meta:
        model = User
        fields = ['url', 'email', 'password', 'my_field']

Eh bien cela ne marchera jamais, avec une erreur qui ne vous met absolument pas sur la voie :

Got AttributeError when attempting to get a value for field `my_field` on serializer `UserSerializer`.
The serializer field might be named incorrectly and not match any attribute or key on the `User` instance.
Original exception text was: 'User' object has no attribute 'my_field'.

Voici la solution : autoriser le null :

class UserSerializer(serializers.ModelSerializer):
    my_field = serializers.CharField(allow_blank=True, allow_null=True)
    class Meta:
        model = User
        fields = ['url', 'email', 'password', 'my_field']

git : exemple de fichier

Voici un exemple de fichier de configuration qui ignore la plupart des fichiers qui posent problème :

# --------------------------------------
# git cleanup if too many files / or / problems:
# git reflog expire --expire=now --all && git repack -ad && git prune
# --------------------------------------
# PyCharm
.idea/
# --------------------------------------
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
# --------------------------------------
# C extensions
*.so
# Distribution / packaging
bin/
build/
develop-eggs/
dist/
eggs/
lib/
lib64/
parts/
sdist/
var/
*.egg-info/
.installed.cfg
*.egg
# --------------------------------------
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# --------------------------------------
# Unit test / coverage reports
.tox/
.coverage
.cache
nosetests.xml
coverage.xml
# --------------------------------------
# Translations
*.mo
# --------------------------------------
# Mr Developer
.mr.developer.cfg
.project
.pydevproject
# --------------------------------------
# Rope
.ropeproject
# --------------------------------------
# Django stuff:
*.log
*.pot
# --------------------------------------
# Sphinx documentation
docs/_build/
# --------------------------------------
# git
objects/
# --------------------------------------
# swap files
*.swp
*.swo

Bootstrap : classes utilitaires

Vous allez peut-être trouver du code qui ressemble à cela :
<p class="mb-0">Texte dans un paragraphe</p>

Bootstrap >= 4 a mis en place plein de possibilités pour faire du padding et des marges « responsives ».
Elles fonctionnent pour tous les breakpoints :

  • xs (<=576px)
  • sm (>=576px)
  • md (>=768px)
  • lg (>=992px)
  • xl (>=1200px)

<p class="{propriété}{côtés}-{taille}">texte</p>

propriété :

  • m – les marges
  • p – le padding

côtés :

  • tmargin-top or padding-top
  • bmargin-bottom or padding-bottom
  • lmargin-left or padding-left
  • rmargin-right or padding-right
  • x*-left and *-right
  • y*-top and *-bottom
  • blank – les 4 côtés à la fois

taille :

  • 0 – supprimer les marges ou mettre le padding à 0
  • 1 – $spacer *0.25
  • 2 – $spacer *0.5
  • 3 – $spacer
  • 4 – $spacer *1.5
  • 5 – $spacer *3
  • auto – margin à auto

Python : faire un « beep » sur Debian

Le code est simple, il fautt avoir paplay d’installé (je ne sais pas si c’est installé par défaut dans Debian).

A partir de là voici un exemple de code qui joue un fichier ogg :

# python3
>>> import subprocess
>>> subprocess.Popen([
... "paplay",
... "/home/olivier/.local/blah/Mission_Failed.ogg"
... ]).poll()
>>>

Sublime Text : licence. Oui. Licence.

Oui.

TAX INVOICE

TAX INVOICE? One image:

Run away!

Je l’ai fait. OUI.
Sublime Text licence bought

J’ai même choisi toutes les catégories dans lesquelles il peut entrer :

  • développement
  • développement divers
  • développement Internet
  • développement Django
  • Php
  • programmation C
  • programmation JavaScript
  • Python
  • geek
  • gestion de projet
  • euh j’arrête, il peut entrer… partout ! (aucune digression, merci !)

Je lutte activement contre la mentalité Française latine : j’essaie d’expliquer à tout le monde qu’il faut arrêter de scier la branche sur laquelle on (= les développeurs) est assise : si vous pouvez avoir quelque chose de gratuit, mais que vous vous en servez souvent, faites le calcul : s’il vous fait économiser du temps, donc de l’argent, bah la conclusion est simple : il faut que cela continue. Pour que cela continue, payez (moins que ce qu’il vous a fait économiser, sinon c’est pas intéressant) mais payez, bon sang !

J’ai évolué de ce côté et je fais tout pour que les personnes que je fréquente – et étudiants – aillent dans ce sens.

Donc oui, Sublime Text me fait gagner du temps tous les jours depuis plusieurs années, et aujourd’hui, la conclusion est évidente : il m’a fait gagner bien plus que 80 €.

Donc… je résume, une image vaut mille mots. Et même si pour certains c’est vieux, le principe reste éternel :

Anastacia - I paid my dues

PS : pour ceux qui ne savent pas ce que « OMFG » signifie, ne le dites à personne, et allez vite chercher sur Internet. Promis on ne le dira à personne. C’est comme « RTFM ». Promis.

python, flask, https et wsgi howto

Je ne vais pas dire le temps que j’ai passé à réussir à mettre ça en oeuvre si quelqu’un fait ça en quelques minutes j’aurais honte… mais disons que j’ai passé beaucoup de temps à le faire tourner, mais je suis vraiment impressionné par sa rapidité. Voici – via ma petite expérience – comment faire tourner un serveur Web très optimisé, en mode production  :
  • flask
  • wsgi
  • https

https / certbot

Je vous donne des pistes, à vous de finir.
L’idée, c’est que je veux paramétrer pour la n-ième fois un nouveau nom de domaine via certbot, et je ne veux pas qu’il touche à la conf de nginx. L’idée c’est que :
(1) Je le fais simplement via certbot-auto puis après,
(2) toutes les autres fois j’utilise « -d » pour qu’il ne touche pas à la conf, et je le fais à la main, en m’inspirant de la conf que cert-bot a fait dans le (1)
Donc, pour faire le (1), je demande à certbot de me créer uniquement le certificat : ./certbot-auto certonly -d monsite.fr
Pour le https, regardez ici.

Python

Code exemple, qui lit un fichier JSON, lance le serveur et sert le fichier lu en tant que JSON :

import json

from flask import Flask, jsonify

app = Flask(__name__)

with open("mon fichier JSON", 'r') as f:
    json_levels_full_description = json.load(f)


@app.route('/')
def index():
    return jsonify(json_levels_full_description)

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8004)
else:
    application = app

Attention : surtout ne faites pas le classique if __name__ == '__main__' car uwsgi inclut ce fichier, donc ce fichier n’est jamais un __main__, par contre la configuration au lancement a besoin d’une variable globale nommée application.

Nginx

Je copie colle la configuration d’un site qui tourne déjà en https, en voici un extrait diminué à mort pour ne pas polluer avec des règles personnelles, regardez bien le texte en gras, c’est le plus important pour faire tourner Nginx en collaboration avec wsgi :

server {
  server_name "~(www\.)?monsite\.(com|fr|org|biz|be)$";

  index index.html index.htm;

  access_log /blah/proxy-access.monsite.log proxylog;
  error_log /blah/proxy-error.monsite.log error;

  listen 443 ssl;
  ssl_certificate /blah/fullchain.pem;
  ssl_certificate_key /blah/privkey.pem;
  include /blah/options-ssl-nginx.conf;
  ssl_dhparam /blah/ssl-dhparams.pem;

  location / {
    include denied_clients;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Server $host;

    # (!) here it's uwsgi:
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:8002;

  }
}

# redirect http -> https:
server {
  listen *:80;
  server_name "~^monsite\..*$";
  return 302 https://$host$request_uri;
}

Flask

Pour installer flask, et uwsgi, faites un environnement virtuel puis installez les deux :

$ python3 -m venv venvpython.3.6.6
$ source venvpython.3.6.6/bin/activate
$ pip install --upgrade pip
$ pip install flask

uwsgi

Il faut être dans le venv activé (voir paragraphe précédent), puis l’installer via pip :

$ pip install uwsgi

Enfin, le script de lancement !

uwsgi --chdir=/web/htdocs/blah \
    --module=flask_server:application \
    --master --pidfile=/tmp/uwsgi.blah.pid \
    --socket=127.0.0.1:8004 \
    --processes=5 \
    --uid=1000 --gid=2000 \
    --harakiri=20 \
    --max-requests=5000 \
    --vacuum \
    --home=/web/htdocs/blah/venvpython.3.6.6

flask_server correspond au fichier python flask_server.pydécrit dans la section python au début et application est le nom de la variable globale (lisez le code de la section python)

Lorsque vous le lancerez, tout se passera bien, mais l’exécutable ne sera pas en tâche de fond. Cela a un avantage : un CTRL-C et vous l’arrêtez ! L’inconvénient, c’est que vous n’avez pas la main.

Si vous voulez le lancer en tâche de fond et qu’il écrive les logs dans un fichier, ajoutez l’option     --daemonize=/var/log/uwsgi/blah.uwsgi.log


Notes d’amélioration :
– Le port 8004 peut être passé en tant que variable d’environnement à l’application flask via le paramètre `env` de la commande uwsgi, ce qui rend le code plus portable ;
– Les paramètres uwsgi peuvent être consignés dans un fichier my_app.ini et uwsgi serait alors lancé en faisant uwsgi my_app.ini

Linux prompt how-to customisé + explications

Je vais faire un résumé de ce que j’ai trouvé un peu partout, et pourquoi j’ai choisi mon prompt tel que je l’ai fait.

  1. Visuellement, avoir quelque chose de coloré est extrêmement parlant. Il me fallait absolument utiliser les couleurs possibles du prompt pour rapidement mettre en évidence ce qui m’intéresse ;
  2. Le bash a sa syntaxe qui est très efficace mais pas forcément facile à appréhender ;
  3. Comme pour tout ce qu’on cherche sur Internet en termes de développement, il y a à boire et à manger… et cela semble devenir vrai aussi pour Linux. J’espère vraiment (x 450e+6654) me tromper.

Ce que j’ai trouvé et qui fonctionne selon mes tests. Ici, bien sûr, peut être qu’il y a d’autres solutions, mais celle que je donne ici a fonctionné sur tous les shells que j’ai testé (Ubuntu, Mint mais aussi CentOS).

Séquence invisible

Toute séquence qu’on ne veut pas visible doit être entourée par \[ et \].
Fin de l’histoire. Je vais pas pleurer en disant que j’ai passé un sacré paquet de temps à trouver ça alors que c’est très simple. Ah si je pleure ? Bon ok.

Changer de couleur

Pour changer de couleur, il faut imaginer qu’on change simplement de stylo. Simple, me direz-vous ? Mais après avoir lu et travaillé dans le Web où on ouvre puis on ferme une balise, ici, non. Il faut envoyer une séquence spéciale : \033 puis ouvrir un crochet qu’on ne va pas fermer, c’est codé en dur, il faut l’accepter tel quel : [. Et ensuite, un chiffre : 0 pour dire qu’on veut une couleur foncée, ou 1 pour dire qu’on la veut un peu plus claire (ex : le noir devient gris) puis un point virgule ;. Ensuite, il faut donner un chiffre compris entre 30 et 36 pour préciser la couleur. Et vous croyez que c’est terminé ? Non ! Il faut terminer par la lettre m. Si vous avez bien lu, vous devriez instantanément comprendre l’exemple suivant : \[\033[1;31m\]. Oui oui, le crochet au milieu ne se ferme jamais. Respirez, calmez-vous. C’est la vie. Il faut faire avec.

Pour toutes les couleurs, j’ai tout mis dans mon mémo qui remplace ma mémoire trop remplie (je préfère dire « trop remplie » que « défaillante », mais parfois j’hésite entre les deux…).

Restorer la couleur d’origine

Oui c’est en h1 parce que c’est aussi important que les deux paragraphes précédents : pour restaurer la couleur d’origine, cela ressemble un peu à l’ordre précédent : entourer par des crochets échappés, une séquence de couleur qui n’a pas deux valeurs mais une seule : 0. Cela donne : \[\033[0m\].
Donc votre code qui change votre prompt devrait toujours se terminer par « remettre la couleur d’origine », soit \[\033[0m\]. Ce n’est que mon point de vue…

Mon prompt

Vous allez me dire « mais pourquoi il fait tout un article sur un prompt ? ». Réponse : c’est comme mon clavier : j’ai passé beaucoup de temps à l’apprendre et le configurer, parce que je sais que sur du long terme ça va m’être très rentable. Passer plusieurs semaines pour gagner plusieurs mois, ça vaut le coup, fin de l’histoire. Donc, voici ma réflexion qui explique mon choix de prompt. J’aurais tout autant pu vous répondre un grand classique indétrônable : le diable est dans les détails.

  1. J’ai très souvent besoin de savoir globalement l’heure qu’il est. J’aimerais bien, dans mon prompt, je sache l’heure qu’il est. Si je tape quelque chose, je valide, hop j’ai la nouvelle heure. Pratique, pas « mortellement pratique », mais sympa. De plus, 6 caractères utilisés pour HH:MM[espace] c’est négligeable. Par contre, j’aimerais que visuellement, ça ne soit pas polluant. C’est pratique, mais pas important. La couleur la plus sombre possible dans le prompt c’est « noir éclairci », soit premier chiffre = éclairci = 1 et second chiffre = noir = 30. Donc mon premier ordre c’est « noir éclairci + heure », donc : \[\033[1;30m\]\t 
  2. La seconde chose, qu’on retrouve partout, c’est bien sûr, qui est connecté, donc l’utilisateur. Là, ça devient plus important. Mais pas le plus important pour moi (surtout sur la fin du prompt où on voit en méga surbrillance, si on est superuser ou utilisateur normal) : c’est une couleur foncée 0 et qui peut avoir un pendant « éclairci » plus agréable pour préciser l’hôte (j’en parle juste après) : j’ai choisi purple = 35. La séquence échappée du user en cours est \u. Ici aussi, si vous avez suivi, ça donne, couleur + user en cours : \[\033[0;35m\]\u
  3. Ensuite, séparateur entre l’utilisateur et l’hôte. Le classique « @ » qui ne doit pas être gênant, même couleur que l’heure : « noir éclairci », soit \[\033[1;30m\]@
  4. L’hôte. Oui, le grand classique c’est «[userconnecté]@[hôte]», et si des millions de geeks linux ont choisi cela c’est que c’est parlant. Mais ici, comme je gère pas mal de machines, selon moi, il faudrait que l’hôte soit un peu plus visible que le user en cours. Donc même couleur que le user, mais avec «1» au lieu de «0». Sachant que la séquence échappée de l’hôte est \h on obtient : \[\033[1;35m\]\h
  5. Avant dernière chose (pour moi) : le path. Là, bon sang, il faut que ça pète. Il faut que le yeux le voient même si on commence à s’endormir (petit clin d’œil à ceux qui mangent kebab-frites avant de commencer les cours avec moi). Un bon rouge, bien éclairci. Allez on le fait rapide : pour exécuter un ordre à chaque appel de prompt, l’astuce est d’échapper le $ et de mettre entre parenthèses l’ordre shell qu’on veut lancer : ici, on est sur du Linux, c’est instantané. La solution, donc : rouge vif + $(pwd) version « échappée » :
    \[\033[1;31m\]\$(pwd)
  6. Dernière information : la plus cruciale, toujours présente sur tous les paths : quel type d’utilisateur est connecté : \$. Il est substitué par # si vous êtes root, sinon $. Là, il faut qu’on ait les yeux qui brûlent. Lunettes de soleil. Du jaune, le plus visible possible (= « 1« ). Un bon jaune qui fait pleurer les yeux, mais ça ne prend qu’un caractère, qui est IMHO, d’une importance cruciale :
    \[\033[1;33m\]\$

Voici donc mon bash résumé en une ligne, que je mets dans tous mes .bashrc. Si vous ne savez pas ce qu’est un .bashrc, je vous laisse chercher, ce n’est pas le but de l’article.

Voici ce que donne mon prompt, et même si ici il n’est pas super vendeur, en pratique, je n’ai pas trouvé quelque chose de plus efficace visuellement parlant, si vous avez des idées / suggestions, améliorations, commme d’habitude, je suis preneur :

Mon prompt Linux shell

Le code de mon prompt, volontairement en minuscules juste pour vous faire râler :

export PS1="\[\033[1;30m\]\t \[\033[0;35m\]\u\[\033[1;30m\]@\[\033[1;35m\]\h \[\033[1;31m\]\$(pwd) \[\033[1;33m\]\$\[\033[0m\] "

PS : pour ceux qui ne savent pas ce que « IMHO » signifie, ne le dites à personne, et allez vite chercher sur Internet. Promis on ne le dira à personne. C’est comme « RTFM ». Promis. Chut. [silence gêné].

Django 2.1 : les autorisations de l’administration grandement facilitées

Voici le (petit) souci que tout le monde a forcément dès qu’on commence à vouloir un peu pousser la customization de l’administration Django : on aimerait avoir la possibilité d’accéder à certains modèles, mais uniquement en lecture seule. J’ai des tonnes d’exemples simples, mais très souvent, ce sont des modèles avec des choix « fixes » qui ne risquent pas d’évoluer dans le temps (exemple : sexe « féminin »/ »masculin »). Seulement (1) on ne veut pas le voir apparaître dans l’admin (2) si on ne veut pas le voir apparaître, il ne faut pas le déclarer, et Django ne veut pas accéder à un modèle qui n’est pas déclaré (= erreur), donc on en arrive toujours à (3) on déclare le modèle, on applique une solution « bidouille » que je ne décris pas ici mais même si le modèle n’apparaît pas dans l’interface, en tapant à la main la bonne URL (facile à deviner qui plus est), on peut tout de même modifier ce modèle. Heureusement la version 2.1 de Django pallie à ce manque !

Eh oui, dans la classe interne «Meta», ils ont fait évoluer default_permissions, qui est écrit en base. Donc en passant à Django 2.1 il vous faudra faire le fameux makemigrations migrate.

Là ou cela devient intéressant, c’est que dans les options vous avez default_permissions et elles sont ('add', 'change', 'delete', 'view'). Le plus important et le nouveau est donc 'view' qui pallie parfaitement au problème expliqué en haut !

Il vous suffit de déclarer votre modèle, de faire la classe dérivée de ModelAdmin et de préciser uniquement ('view',).
Attention, je n’ai pas testé, si quelqu’un veut tester et confirmer que ce code fonctionne (ou pas), je suis preneur !

class SexeAdmin(models.ModelAdmin):
    class Meta:
        default_permissions = ('view',)

Plein de code en moins, plus aucune bidouille ici, plus de lisibilité, bref, de mieux en mieux !