Lieu de stockage des templates

Surtout pas (ce qui pourrait paraître logique), /mon_projet/app1/templates/index.html et /mon_projet/app2/templates/index.html. Si vous le faites vous risquez de charger le fichier index.html de app1 lorsque vous appelez app2.

Vous avez le choix :

• dans /mon_projet/app1/templates/app1/index.html (idem pour app2 évidemment).
• dans /mon_projet/templates/app1/index.html (idem pour app2).

Personnellement je préfère la deuxième solution car le chemin est moins compliqué.

Configuration du fichier settings.py

• Au niveau de la variable TEMPLATE_LOADERS, vous devez avoir la ligne suivante :
  'django.template.loaders.filesystem.Loader'

• Au niveau de la variable TEMPLATE_DIRS, les chemins d’accès aux templates doivent être déclarés :
  Si vous avez choisi la première option pour le stockage des templates :
  os.path.join(ROOT, "app1/templates"),
os.path.join(ROOT, "app2/templates"),
  Si vous avez choisi la seconde option :
  os.path.join(ROOT, "templates"),
  Ceci suppose que vous avez déclaré en début de fichier :
  ROOT = os.path.dirname(os.path.abspath(__file__))

Chargement des templates

Lors du chargement des templates, il faut préciser le nom de l’application : app1/index.html et app2/index.html

Ainsi pour une utilisation en production, on le couple à un serveur http, par exemple le très célèbre Apache. Pour ce faire on va utiliser l’interface standard Python : WSGI (Web Server Gateway Interface). Un exemple de configuration est fourni sur la documentation officielle de Django.

Cependant il existe un moyen à mon avis plus élégant de parvenir au but recherché : l’utilisation de gunicorn en tant que proxy. Je n’ai pas eu encore l’occasion de le tester autrement qu’en local, mais il s’avère très prometteur en terme de rapidité. De plus, une fois gunicorn installé (très simple puisqu’il s’agit d’un package Python), la configuration est vraiment aisée.
Plutôt que de paraphraser, je vous renvoie vers un article très bien fait.

Important : il faut s’assurer que les chemins vers l’application Django définis dans la configuration d’Apache sont bien accessibles par l’utilisateur qui exécute Apache.

1) Dans votre settings.py, le processeur de contexte de template django.core.context_processors.request doit être présent en plus de ceux définis par défaut, ce qui donne :

TEMPLATE_CONTEXT_PROCESSORS = (
'django.core.context_processors.auth',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
'django.core.context_processors.request',
)


2) Dans la vue (views.py), il faudra passer un objet de type RequestContext si vous utilisez la méthode render_to_response, ce qui donne par exemple :

...
request.session['hello'] = 'world !!!'
return render_to_response('index.html', context_instance=RequestContext
(request))


3) Vous accédez à votre variable de session, dans votre template de cette façon :

value : {{ request.session.hello }}


Pour la rédaction de cet article, je me suis basé sur la documentation de Django. L’installation a été réalisée sur un serveur fonctionnant avec Debian Lenny.

Installation de WSGI

aptitude install libapache2-mod-wsgi

Paramétrage de l’application pour l’utilisation d’Apache

Pour ce faire créez par exemple un répertoire apache à la racine de votre site et ajouter un fichier nommé django.wsgi. Ajoutez les lignes suivantes :
import os
import sys
sys.path.append('/usr/local/src/django_apps/app/')
os.environ['DJANGO_SETTINGS_MODULE'] = 'monprojet.settings'
import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Adaptez les lignes 3 et 4 à votre projet. Attention la ligne sys.path.append contient le chemin vers votre projet, nom du projet NON compris.

Il faut ensuite ajouter à Apache le site développé avec Django. Ajoutez par exemple à votre virtualhost les lignes suivantes :

Alias /media/ /usr/local/src/django_apps/app/monprojet/media/

<Directory /usr/local/src/django_apps/app/monprojet/media>
Order deny,allow
Allow from all
</Directory>

WSGIScriptAlias /monprojet /usr/local/src/django_apps/app/monprojet/apache/django.wsgi

<Directory /usr/local/src/django_apps/app/monprojet/apache>
Order deny,allow
Allow from all
</Directory>

• La ligne avec Alias permet de définir un chemin pour indiquer à Apache où aller chercher les fichiers statiques (images, css…).
• La ligne avec WSGIScriptAlias définit l’URL pour l’appel de votre site.
• Les directives avec Directory donnent l’accès aux répertoires à Apache

Voilà, ne pas oublier de recharger la configuration d’Apache.

/etc/init.d/apache2 reload

Contexte :

• Debian Lenny
• Django 1.1 installé
• PostgreSQL 8.3.6, installé à partir des sources

Pourtant PostgreSQL est bien lancé, la base est accessible en utilisant l’utilitaire psql…

Eh bien quoi alors ?

Si on y regarde de plus près, il y a bien un fichier .s.PGSQL.5432, mais il est dans /tmp… en faisant:$ mkdir /var/run/postgresql
$ ln -s /tmp/.s.PGSQL.5432 /var/run/postgresql/

cela fonctionne !
A noter que le problème ne se pose pas si on installe PostgreSQL à partir du gestionnaire de paquets…

Edit : autre solution :

A priori le problème vient de cette version de la bibliothèque python-psycopg2 (utilisée par Django pour la connexion avec PostgreSQL) qui a en dur le chemin /var/run/postgresql. Une autre solution consiste à spécifier au serveur PostgreSQL le chemin qu’il doit utiliser pour stocker la socket de connexion. Pour ce faire, éditer le fichier postgresql.conf et mettre :

unix_socket_directory = '/var/run/postgresql'

Dans le cadre de ma participation au projet de domotique Domogik, je suis en charge de développer la partie interface graphique qui devra fonctionner avec un navigateur. Le coeur du code de domotique étant déjà écrit en Python, nous avons pensé qu’il serait bien de rester homogène.

Evidemment avant de réinventer la roue (et donc de développer une application de A à Z), il vaut mieux voir ce qui a déjà été fait. Nous avons donc choisi le framework Django qui paraissait complet et simple à utiliser. Pour information, un framework est une base de travail qui contient un ensemble de composants logiciels, de conventions sur lequel votre code va s’appuyer. Les bénéfices sont la rapidité de développement et l’homogénéité des traitements dans votre application, ce qui facilitera la maintenance / les évolutions.

Alors pourquoi Django ?

Django est ce qu’on appelle un MVC (Modèle, Vue, Contrôleur) c’est à dire qu’il propose une architecture qui isole le modèle de données, le pilotage de l’application (contrôles, logique d’enchaînement des pages) et la présentation (l’affichage du contenu).

Voici les points forts de Django :

• Il est simple d’utilisation. A partir du moment où vous avez des connaissances en programmation et quelques notions de Python, vous êtes opérationnels en très peu de temps.
• Il est puissant : le meilleur exemple est la façon dont il gère les données. Pour être concret, je vous donne un aperçu :
  class Langage(models.Model):
LANG_CHOICES = (
('l1', 'Python'),
('l2', 'Java'),
('l3', 'Php'),
('l4','Perl')
)
name = models.CharField(max_length=30, choices = CAPACITY_CHOICES)
desc = models.CharField(max_length=255)

  Rien qu’avec ce morceau de code et avec l’exécution d’une simple ligne de commande, Django va :

  1) Générer le script SQL et créer toute la structure (les tables internes à Django ainsi que la table langage).
  2) Générer automatiquement une interface web qui va vous permettre de saisir les différents langages. Ici dans cet exemple j’aurai automatiquement une liste déroulante avec les quatre éléments ainsi qu’un champ texte pour saisir une description.
  3) A noter qu’il est possible de spécifier des clés étrangères, des relations n-aires… C’est pas magique ?

• Il propose un système de templates efficace pour la partie présentation. En gros vous décrivez la structure de vos pages dans un fichier et ensuite pour chacune des pages vous redéfinissez simplement ce qui est spécifique (titre, contenu…).
• Il est indépendant de la base de données. Un simple paramétrage dans le fichier de configuration (settings.py) et vous passez d’une base à l’autre. J’ai fait le test en utilisant MySql et PostgreSQL !
• Il dispose d’un serveur de développement intégré. Pas besoin dans un premier temps d’avoir un serveur web configuré pour qu’il puisse fonctionner avec Python. De plus ce serveur est très léger et très rapide.
• La documentation de Django est excellente : complète et pédagogique. Je vous conseille notamment l’excellent tutoriel (anglais) qui va vous permettre d’être opérationnel en très peu de temps. Il existe une version française mais attention elle se base sur Django 0.9, alors que la dernière version est 1.0, ce qui peut poser quelques problèmes de compatibilités notamment dans certains noms de variables. En revanche le principe reste le même donc vous pouvez le lire pour avoir une vision d’ensemble.
• Il est facile à installer : il faut avoir Python (vaut mieux, hein ?) et les paquets MySql (python-mysqldb) et / ou PostgreSQL (python-pgsql, python-psycopg). Ensuite il suffit de décompacter l’archive de Django et de lancer le setup.
• Il est écrit en Python : oui je sais les goûts et les couleurs… Cependant en toute objectivité Python est un formidable langage : il est puissant et simple d’utilisation. Venant du monde Java, je pense savoir de quoi je parle…

Voilà donc pour cette présentation. Il existe d’autres frameworks tels que Turbogears mais je ne le connais pas donc s’il y en a qui ont une opinion, n’hésitez pas à laisser un commentaire.