Accueil > Multimédia > Déploiement d’un site avec Django/Rails

Déploiement d’un site avec Django/Rails

samedi 11 janvier 2014, par thehardway

[(Préambule : Django 1.6 vient de sortir, apportant un lot d’améliorations attendues par nombre d’utilisateurs. C’est pour moi l’occasion de libérer cet ancien article dans l’attente d’un autre plus avancé ou plus spécialisé sur le sujet. En tous les cas, l’idée est ici de mettre en avant un langage et un framework qui me tiennent plutôt à coeur. Non pas que je ne jure que part ce type de technologie, mais parce qu’elle parle à mes affinités de développement, mes procédures mentales, ma recherche de rigueur tout à fait personnel et par un bon équilibre entre rapidité et charge.
L’article ci-dessous aborde essentiellement l’installation des frameworks Django & Rails ; fameux frères ennemis aussi intéressants l’un que l’autre, bien que Django notamment par la littérature en français qui lui est consacré, me séduise plus fortement.
La version de Django en question dans cet article est la 1.5. Le sujet demeure l’installation des deux frameworks et le déploiement des fichiers.)]


Installation de Django

Simple et facile. Suivez à la lettre l’option 1 de cette page.

Exemple.
Sur MacOSX par exemple, j’ouvre le terminal (appel de spotlight et frappe de ’terminal’). En parallèle via mon navigateur je télécharge la dernière version de Django qui arrive donc dans mon répertoire ’téléchargement’. Dans la console je me place dans le dit répertoire (CD downloads). Si jamais vous souhaitez connaître la liste de vos répertoire tapez ’ls’ dans la console.
Une fois dans le répertoire, décompresser votre téléchargement en tapant/copiant dans la console ’tar xzvf Django-1.4.1.tar.gz’. (à adapter selon le numéro de version)

Le répertoire obtenu, vous pouvez le déplacer par exemple dans ’documents’. Dans la console placez-vous dans le répertoire choisi en utilisant cd .. pour revenir en arrière et cd NOM DU REPERTOIRE pour entrer dans le répertoire.
Là tapez dans la console ’cd Django-1.4.1’ et ’sudo python setup.py install’.

Voilà c’est fait !

Pour être certains.
Relancer votre console. Tapez ’python’ pour appeler le langage. Puis au prompt de python (>>>) tapez :
>>> import django
>>> print(django.get_version())

ou alors directement à l’ouverture de la console tapez : python -c « import django ; print(django.get_version()) » (même chose en une seule fois)

vous obtenez le numéro de version de votre Django. Tout est OK.


Installation de Ruby on rails
Comparativement Rails du moins dans ses premières version semblait d’une approche plus lourde. Au premier abord seulement ! En effet, certains outils simplifient considérablement une installation initiale à la ligne de commande plutôt longuette. Ainsi il suffit de télécharger l’excellent RAILSINSTALLER et de suivre les instruction de l’installeur (incluant GIT !) et le tour est joué pour une version à jour du framework (au moment d’écrire ces lignes la version 3.x.x) Pour vérifier votre version, allez dans la console/terminal de votre système et taper rails -v Bien entendu, si vous ne souhaitez pas utiliser cet installeur, vous devrez généralement dans votre console/terminal taper ceci en tant qu’administrateur/root : # gem install rails Cette gem fait le travail en une seule ligne dans le meilleur des cas. Pour windows il existe également : http://rubyinstaller.org/ Cela dit, si la ligne de commande ne vous fait pas peur, l’installation de Rails induit généralement celle de git (pareil pour django d’ailleurs), de RVM de rubygem. Le tout prend un peu plus de temps que pour un Django. Je vous conseille deux sites au sujet de l’installation de Rails.

Création du projet
Allez Hop retournez dans votre console
Choisissez un nom pour le dossier qui contiendra votre premier projet.
tapez dans la console : django-admin.py startproject nomduprojet

Magique : un dossier au nom de votre projet est créé. Il contient un sous dossier du même nom, contenant lui 3 à 4 fichiers.
ICI un résumé des fichiers créés

Avec rails c’est encore moins verbeux et aussi simple : dans votre console taper rails new nomduprojet
En revanche rails créé bien plus de fichiers et de dossiers que Django. La plupart n’auront pas une utilité immédiate, mais la masse est impressionnante.

Bon mais de quoi ça parle Django ?
Avec Django (tout comme avec Rails), vous créer des sites. Mais attention ce n’est pas un CMS classique ou tout est pré-construit, encapsulé, borné, un robot à qui l’on donne des ordres. Certes un CMS est rapide à déployer, immédiatement visitable et facilement renseignable ou upgradable (pour les meilleurs) - et c’est exactement pour cela que l’on aime un CMS - mais il reste corseté par son modèle d’administration et d’habillage graphique. Les nouveaux CMS s’ouvrent de plus plus à la customisation, l’adaptation, laissant les bidouilleur toucher à leur moteur. Mais dans ce cas là il se rapproche plus des Frameworks.
Ces derniers sont des ossatures et non des modèles complets, permettant de créer et non de composer des sites. Nuance ! Avec un CMS on compose un site, avec un framework on créé un site à l’aide d’une boîte à outil facilitant la construction des fonctionnalités du site.

Je ne m’étendrais pas plus sur le sujet. Django est un FRAMEWORK (qui par ailleurs à donné lieu à des version CMS comme django-cms ou mezzanine)

La logique Django :
Le fichier urls.py contient les pointeurs vers les pages HTML avec lesquelles les visiteurs interagiront.
Le fichier views.py contient des fonctions propres aux pages HTML. Ces fonctions permettront de passer des données aux pages HTML. C’est ici que les traitements de toutes données aura lieu et les résultats passés aux pages HTML. Des pans entiers de codes HTML peuvent se trouver dans ces fonctions (mais ce n’est pas l’idée). Le nom de ces fonctions est celui de la page appelée par le visiteur.
Les fichiers templates de type HTML. Les fameuses pages .html qui seront affichées. Elles recevront des infos des fonctions du fichier view.py. Leurs noms est en rapport avec celui de la fonction qui lui est corrélée.
Le fichier setting.py où l’on définie les grands paramètres globaux du site, les chemins vers des répertoires de référence, les codages, etc ...
http://www.naeka.fr/blog/2010-insta...
http://django-story.readthedocs.org...

Les grandes lignes du champ des possibles.
Résumons ici la logique de constructions et les incontournables.
Les pages HTML ou autre :
elles peuvent s’appeler entre-elles pour construire une page définitive. On peut ainsi imaginer une base commune à toutes les parties constituantes de son site (par exemple pour l’entête et le pieds de page de chaque écran). Cette base pourra être héritée par les pages spécialisées du site.
Ici la balise {% extends "nomdelapage.html" %} est un incontournable. Elle injecte une ossature de balises html - ou autres - dans la page qui l’appel.

Encore plus fort, cette page de base possèdera des zones (notion de block) qui pourront se modifier en fonction de la page qui l’appellera tout en passant des informations aux blocks. Pour cela on utilise la forme {% block identifiant du block %}quelque chose{% endblock %}.

Par exemple, le titre de chaque page est généralement différent. Notre page de base intègre donc la balise html <title>titre de la page de base</title> dans son en-tête. Lorsqu’une autre page appellera la page de base, elle recevra <title>titre de la page de base</title>.

Sauf que si l’on ne fait rien le titre ne correspondra pas à la page en cours. Pour contourner cela on utilise donc la logique de block : {% block identifiant du block %}quelque chose{% endblock %}.
La balise title devient dans la page de base : {% block title%} nom de la page de base{% endblock %}.
Ainsi lorsque la page courante appellera cette partie, elle passera un autre nom dans le block identifié « title ».

Par exemple {% block title %}Connexion{% endblock %}. Ici le mot Connexion remplacera le nom de la page de base.

Nous sommes là dans la gestion classique de l’héritage et de l’imbrication.

Récupérer les données dans la requête HTTP

Faire un formulaire
1) Créer un fichier form.py afin de placer les classes et fonction propres aux formulaires
2) Utilisation de la bibliothèque native pour les formulaires :
from django import forms
appel de la bibliothèque dans le fichier form.py
3) initiation de la classe pour un formulaire
class nomdelaclasse(forms.Form) :
4) création des champs du formulaire :

  • email = forms.EmailField(label=’votre email’)
  • nom=forms.CharField(label=’votre Nom’, initial=’Votre Nom ici’ , max_length¶=50, min_length=2, help_text=’Nom entre 2 et 50 caractères.’ , error_messages=’required’ : ’Merci de saisir obligatoirement votre Nom’)
  • prenom=forms.CharField(label=’votre Prénom’, required=False)
  • motdepasse = forms.CharField(label=’votre mot de passe’, widget =forms.PasswordInput)
  • newsletter = forms.BooleanField(label=’bulletin’, help_text=’je m’abonne au bulletin trimestriel’, required=False)
  • commentaire = forms.CharField(label=’commentaire’, required=False, widget=forms.Textarea)
  • CONNU_LISTE = ((’1’, ’Option 1’),(’2’, ’Option 2’),(’3’, ’Option 3’),)
  • connu = forms.ChoiceField(choices=CONNU_LISTE)

L’exemple ci dessus est donc assez complet. Il faut en retenir les bases suivantes :
les Widget servent à modéliser certains formats, par exemple pour le champ « mot de passe » qui demeure avant tout un champ de type caractères génériques (CharField). Ou encore le widget qui permet d’avoir un champ de texte très large (Textarea)

Créer des contrôleurs de données

Pour rails la commande generate permet de créer un contrôleur et de lui passer des actions. Exemple : rails generate controller Salutations bonjour aurevoir. Noter que le nom du contrôleur porte une majuscule et le nom des actions est en minuscule. Cette commande créera un fichier pour le contrôleur et autant de fichier de type .html.erb pour les actions définies.
Pour django le fichier views permet d’accueillir la rédaction de contrôleurs. Mais rien n’empêche de créer de nouveau fichier contrôleurs de type .py

Pour finir, quelques sources documentaires.

migration php django
http://www.naeka.fr/blog/2012-migra...

Hébergeurs
http://sametmax.com/quel-hebergemen...

gratuit et payants
https://www.alwaysdata.com/plans/shared/
Payants
http://djangoeurope.com/signup/
http://www.webfaction.com/features

Livre gratuit
http://www.djangobook.com/en/2.0/in...
https://larlet.fr/david/biologeek/a...
http://fr.openclassrooms.com/inform...

Présentation
http://thomas-sebire.net/blog/2012/...

Rails vs Django
http://fr.scribd.com/doc/121814/Rai...
http://www.youtube.com/watch?v=cb9K...
http://maxivak.com/python-django-vs...

Tutos Django
http://tutos-django.com/categories/...
http://www.satchmoproject.com/trac/...

Essais
http://www.bourzeix.com/weblog/post...
http://blog.pilotsystems.net/2011/j...