Cette fois je fais la démonstration des URLS nommées, qui permet d’avoir un découplage propre entre les vues, le template et les routes.

Comme d’hab il y a une version française et anglaise commentées, et comme d’hab, ça m’a pris 3 plombes alors que je m’étais dis que cette fois, promis, je ferai court.

Je sers la science et c’est ma joie.

J’en ai profité pour faire quelques modifs sur les anciennes apps:

• Descriptions plus claires et complètes.
• Quelques ambiguïtés levées.
• Un lien de retour ajouté sur chaque page.

J’ai aussi ajouté des tests unitaires (pas dans la partie snippet, qui doit rester simple) pour m’assurer que je ne casse pas tout à chaque ajout.

Je pensais qu’ajouter une nouvelle app, quand l’app est aussi simple au moins, serait très rapide. Je m’assurais ainsi quelques articles simples et rapides à pondre.

Mouahahah, jeune incrédule.

Pour faire ces modifs ça m’a pris près de 3 heures : il faut bien réfléchir pour rendre les notions à la fois simples et utiles, mettre les bons comments, traduire tout ça de l’anglais vers le français, s’assurer que les deux branches soient bien synchro, ajouter les tests…

En me lançant dans le truc, je m’étais dit “pourquoi personne ne l’a fait avant ? C’est tellement évident que ça manque à la doc”. Maintenant je sais pourquoi. C’est long. Très très long.

Ainsi est né django-quicky, une petite app qui permet de faire du routing et du rendering déclaratif en Django.

pip install django-quicky

Par toutes les routes

Vous avez envie d’un site, maintenant, tout de suite. Mais il faut créer l’urls.py, et les vues, et les mapper. Et jongler entre les deux fichiers.

Ou alors vous pouvez juste faire:

from django_quicky import routing
 
url, urlpatterns = routing()
 
 
@url('/une/regex/que/django/comprends')
def une_vue(request):
    ...
 
 
@url('/on/peut/cummuler/les/routes')
@url('/une/regex/que/django/comprends')
def une_vue(request):
    ...

Le résultat est parfaitement compatible (et mélangeable) avec le routing habituel de Django. Il suffit juste d’utiliser views.py à la place d’urls.py, par exemple dans URL_ROOT ou dans include().

Rien ne vaut une bonne renderette

Declarer sa vue, c’est comme les jupes, c’est de plus en plus court avec le temps qui passe (et la méthode render()). Mais on peut faire encore plus court, genre limite tanga:

from django_quicky import view
 
@view(render_to='template.html')
def une_vue(request):
    return {'truc': truc}
 
 
@view(render_to='json')
def une_vue_json(request):
    return {'truc': truc}

Dans la première vue, le dico est utilisé comme contexte pour faire le rendu du template. Dans la seconde vue, le dico est retourné sérialisé en JSON.

On change de position ?

Des fois vous êtes sur une bonne lancée, mais vous voudriez changer juste un truc. Et garder le code précédent bien sûr. C’est d’ailleurs pour ça qu’on nous vend les CBV, c’est tellement plus flexible !

Vous aimez la souplesse ? Voici de quoi mettre les chevilles très près des oreilles:

from django_quicky import view
 
@view(render_to='template.html')
def vue_commune(request):
    return {'stuff': stuff}
 
@vue_commune.post()
def vue_POST(request, context):
    # do more stuff
    return context
 
@vue_commune.ajax(render_to='json')
def vue_AJAX(request, context):
    return context

On a ici une seule et même vue. La première partie est rendue sous forme de template si on y arrive par une requête GET ordinaire. La seconde si c’est une requête POST. La troisième si c’est une requête en AJAX, avec rendering JSON en prime. Et les deux dernières récupèrent toujours le résultat de la première avant de s’exécuter, ce qui permet d’avoir le code en commun dans la première.

C’est sous licence zlib.