Migration vers Django 1.3
Par Florian Strzelecki -
Sur ma liste des choses à faire, il y avait cette migration concrète de mon site&blog vers Django 1.3. Il faut savoir que j'ai développé à l'origine avec la version 1.1, en ajoutant à l'occasion quelques petites choses de Django 1.2 lorsque j'ai mis à jour mon serveur.
Aujourd'hui, mes dernières applications sont développées avec Django 1.3, et il y a quelques petites choses en plus que j'apprécie bien. Je vous propose donc un retour d'expérience, avec un tour d'horizon de ce que j'ai modifié et eu à modifier.
Nommer les urls
Je n'avais pas touché à mon fichier urls.py
depuis longtemps, et j'ai donc commencé par là : remettre certains trucs à plat, et rendre le tout plus propre et plus facile à maintenir.
Premier truc : utiliser la fonction url
, qui permet entre autre chose de nommer ses urls, ce qui est très pratiques pour la suite, comme, par exemple, ne pas s'embêter à écrire des urls en dur dans les templates.
Exemple de template (avec Django 1.3) :
{% load url from future %}
<p>Lire l'article : <a href="{% url 'entry' entry.url %}">{{entry.title}}</a></p>
Vous noterez l'usage de {% load url from future %}
, car le template-tag url
a un comportement modifié pour les futures version de Django.
Du côté de la view
, cela permet aussi de se simplifier la vie :
def redirect_to_tag(request, section_url):
"""Section now redirect to tag."""
return redirect('tag', permanent=True, tag_url=section_url)
J'ai simplement nommé l'une de mes urls "tag", et la fonction redirect
s'occupe du reste. Si je change la forme des url des tags, je n'aurai pas à changer le code de cette view.
Séparer media et static
Apparu avec Django 1.3, la gestion des fichiers "statiques" a été grandement amélioré par l'intégration de django-staticfiles directement dans le projet Django en tant que django.contrib.staticfiles.
J'ai pu découvrir son fonctionnement avec mon dernier projet (un truc secret pour le moment...), et c'est vraiment très pratique. Le principe ? Au lieu d'avoir un répertoire de médias, intégrant les fichiers de l'application (css, js, etc.) et les fichiers téléversés par les utilisateurs, il y a maintenant deux espaces différents.
Je ne vais pas détailler ici tout ce que j'ai eu à faire mais voici un rapide résumé :
- ajout de l'application
django.contrib.staticfiles
dans la liste desINSTALLED_APP
- ajout des directives
STATIC_ROOT
,STATIC_URL
,STATICFILES_DIRS
etSTATICFILES_FINDERS
- utilisation de
{{STATIC_URL}}
dans mes templates à la place de{{MEDIA_URL}}
Ensuite, pour lancer la collecte, la commande suivante fonctionne très bien :
python manage.py collectstatic
Au passage, j'ai aussi simplifié un peu ma configuration Apache, mais ça, c'est un autre sujet.
Et d'autres petites choses...
S'il n'y avait que ça, ce serait trop facile. Et bien, en réalité : il n'y avait que ça.
J'avais déjà fait une première passe pour simplifier grandement le code, faire le ménage, et retirer ce qui n'était pas bien fait et/ou bien pensé (avec un code qui a presque deux ans, c'est normal, j'ai beaucoup appris pendant ce temps). Du coup, une migration assez simple, avec, au déploiement, pas un seul soucis.
J'ajoute, au passage, que c'est une bonne expérience, qui permet de revenir sur ce qui a été fait avant, et sur ce que je fais aujourd'hui - et donc, de pouvoir mesurer l'écart.