Django vu par un utilisateur de Rails (1)
Tout ce que vous allez lire est à prendre avec des pincettes car je ne suis qu'au début de ma découverte du framework Django. Je suis donc loin d'être un spécialiste de Django et je ne fais que donner « mon ressenti à chaud » par rapport à un autre framework que je connais mieux : Rails.
Création d'un projet
Après avoir installé Django (ce qui fera sans doute l'objet d'un autre article), première surprise de taille à la création d'un projet :
Mais alors, où sont mes modèles, mes controllers, mes vues et tout le toutim ? Va falloir y aller à la mimine mon gars ! (python manage.py startapp xxx sera notre ami la prochaine fois)
Moins de ciment entre les briques
Bien que ce soit « troublant » lorsqu'on vient de Rails, on ressent rapidement une plus grande liberté d'action et d'organisation ainsi qu'une meilleure compréhension du framework si j'essaie de me rappeler de l'époque de ma prise en main de Rails (même si ça date un peu maintenant). Les briques de Django sont moins étroitement liées que celles de Rails ce qui ouvre un « champ des possibles » plus important en terme d'organisation mais au détriment d'une production de code « initiale » également plus importante. Rails demande moins de code initial mais au détriment de conventions plus lourdes. Il faut penser « à la Rails » alors que je n'ai pas eu l'impression d'avoir à penser « à la Django » jusqu'à maintenant (enfin... beaucoup moins).
On se sent également plus proche du langage sous-jacent (Python pour Django vs Ruby pour Rails). Bizarre comme sensation. Encore une fois, c'est juste un ressenti personnel que je livre « tel quel » sans pour autant me l'expliquer réellement pour l'instant (juste peut-être parce que Rails dispose au départ de plus de « magie » que Django ?). Évidemment, la syntaxe de Python étant nettement moins « human friendly » que celle de Ruby, ça va certainement à terme user mes nerfs et mes yeux (Wait & See).
Du coup, pour un petit projet, Django est certainement beaucoup plus adapté que Rails. L'artillerie à mettre en place est beaucoup plus légère, on n'a pas l'impression de sortir un « canon de 75 » pour tuer un moustique. Attention ! je ne dis surtout pas que Django n'est pas adapté aux gros projets (je pense même l'inverse si j'entrevois bien ses possibilités et sa logique qui me laisse la mienne). Je dis juste que si j'avais un site léger (dynamique ou pas) à mettre en ligne, j'opterais sans hésiter pour Django même en l'état actuel de mes pauvres connaissances (d'ailleurs, si Merb existe, ce n'est pas pour rien ^^).
MVC ? MVT ?
Un autre point déroutant au départ est la vision d'un MVC par Django. En résumant, ses vues seraient les controllers de Rails et ses templates seraient les vues de Rails. On pourrait plus parler d'un pattern MVT (Model-View-Template). En fait, en creusant un peu, c'est surtout une histoire de vocabulaire et de définition. Pour Django, les vues décrivent les données qui vont être présentées à l'utilisateur mais ne tient pas compte de la forme (ce sont les templates qui s'occupent de cela). Pour Rails, c'est le contrôleur qui détermine quelles données seront présentées et ce sont les vues qui les mettent en forme. Pas de quoi fouetter un chat une fois qu'on a fait le point sur le sujet. Juste une question d'angle de « vue » (mouarf !).
Template (équivalent Vues de Rails)
Le système de templates de base de Django est surprenant mais réellement pertinent. « Surprenant » parce qu'on ne peut pas y insérer directement du code Python et « pertinent » parce que ça oblige à réellement séparer « la logique métier » de la présentation. Avec Rails, on peut rapidement se laisser aller à ne pas respecter ce point (mode goret ON). On doit donc se limiter aux tags de Django même s'il est à noter que sa souplesse nous autorise à utiliser un autre système de template ou à étendre celui existant. Quelques tags m'ont fait sourire car on sent bien l'adéquation aux cas rencontrés. A titre d'exemple, pour les boucles 'for', le 'forloop.counter' permet de savoir le nombre de fois qu'on a parcouru la boucle, le 'forloop.last' (booléen) permet de savoir si c'est le dernier élément de la liste parcourue (et donc, de ne pas mettre de "|" après le dernier élément d'une liste pour un menu par exemple. Le 'forloop.first' existe également). Bref, par expérience, des « tags malins » et une syntaxe 'template' très propre. L'héritage de template devrait permettre de garder une organisation propre tout en offrant un maximum de possibilités (à tester avec des cas m'ayant posé des soucis avec Rails).
Un autre point particulièrement soigné de Django, ce sont les pages d'erreurs. Du bonheur ! Contrairement à celles de Rails, elles permettent réellement d'aider à débugger. Ça dépasse largement le cadre de la page d'erreur. Rails devrait s'en inspirer.
La suite au prochain épisode.
Création d'un projet
Après avoir installé Django (ce qui fera sans doute l'objet d'un autre article), première surprise de taille à la création d'un projet :
$ django-admin.py startproject taisteuhOn ne peut pas dire qu'on est embarrassé par le nombre de fichiers générés ! Un peu déroutant lorsqu'on vient de Rails mais finalement une bonne surprise pour la courbe d'apprentissage. Comme je ne veux pas transformer ma bafouille en didacticiel, je résumerai en disant que "settings.py" est un peu le pendant "de l'environment.rb et du database.yml cumulés" alors que "urls.py" serait le "routes.rb" de Rails.
$ cd taisteuh
$ ls
__init__.py manage.py settings.py urls.py
Mais alors, où sont mes modèles, mes controllers, mes vues et tout le toutim ? Va falloir y aller à la mimine mon gars ! (python manage.py startapp xxx sera notre ami la prochaine fois)
Moins de ciment entre les briques
Bien que ce soit « troublant » lorsqu'on vient de Rails, on ressent rapidement une plus grande liberté d'action et d'organisation ainsi qu'une meilleure compréhension du framework si j'essaie de me rappeler de l'époque de ma prise en main de Rails (même si ça date un peu maintenant). Les briques de Django sont moins étroitement liées que celles de Rails ce qui ouvre un « champ des possibles » plus important en terme d'organisation mais au détriment d'une production de code « initiale » également plus importante. Rails demande moins de code initial mais au détriment de conventions plus lourdes. Il faut penser « à la Rails » alors que je n'ai pas eu l'impression d'avoir à penser « à la Django » jusqu'à maintenant (enfin... beaucoup moins).
On se sent également plus proche du langage sous-jacent (Python pour Django vs Ruby pour Rails). Bizarre comme sensation. Encore une fois, c'est juste un ressenti personnel que je livre « tel quel » sans pour autant me l'expliquer réellement pour l'instant (juste peut-être parce que Rails dispose au départ de plus de « magie » que Django ?). Évidemment, la syntaxe de Python étant nettement moins « human friendly » que celle de Ruby, ça va certainement à terme user mes nerfs et mes yeux (Wait & See).
Du coup, pour un petit projet, Django est certainement beaucoup plus adapté que Rails. L'artillerie à mettre en place est beaucoup plus légère, on n'a pas l'impression de sortir un « canon de 75 » pour tuer un moustique. Attention ! je ne dis surtout pas que Django n'est pas adapté aux gros projets (je pense même l'inverse si j'entrevois bien ses possibilités et sa logique qui me laisse la mienne). Je dis juste que si j'avais un site léger (dynamique ou pas) à mettre en ligne, j'opterais sans hésiter pour Django même en l'état actuel de mes pauvres connaissances (d'ailleurs, si Merb existe, ce n'est pas pour rien ^^).
MVC ? MVT ?
Un autre point déroutant au départ est la vision d'un MVC par Django. En résumant, ses vues seraient les controllers de Rails et ses templates seraient les vues de Rails. On pourrait plus parler d'un pattern MVT (Model-View-Template). En fait, en creusant un peu, c'est surtout une histoire de vocabulaire et de définition. Pour Django, les vues décrivent les données qui vont être présentées à l'utilisateur mais ne tient pas compte de la forme (ce sont les templates qui s'occupent de cela). Pour Rails, c'est le contrôleur qui détermine quelles données seront présentées et ce sont les vues qui les mettent en forme. Pas de quoi fouetter un chat une fois qu'on a fait le point sur le sujet. Juste une question d'angle de « vue » (mouarf !).
Template (équivalent Vues de Rails)
Le système de templates de base de Django est surprenant mais réellement pertinent. « Surprenant » parce qu'on ne peut pas y insérer directement du code Python et « pertinent » parce que ça oblige à réellement séparer « la logique métier » de la présentation. Avec Rails, on peut rapidement se laisser aller à ne pas respecter ce point (mode goret ON). On doit donc se limiter aux tags de Django même s'il est à noter que sa souplesse nous autorise à utiliser un autre système de template ou à étendre celui existant. Quelques tags m'ont fait sourire car on sent bien l'adéquation aux cas rencontrés. A titre d'exemple, pour les boucles 'for', le 'forloop.counter' permet de savoir le nombre de fois qu'on a parcouru la boucle, le 'forloop.last' (booléen) permet de savoir si c'est le dernier élément de la liste parcourue (et donc, de ne pas mettre de "|" après le dernier élément d'une liste pour un menu par exemple. Le 'forloop.first' existe également). Bref, par expérience, des « tags malins » et une syntaxe 'template' très propre. L'héritage de template devrait permettre de garder une organisation propre tout en offrant un maximum de possibilités (à tester avec des cas m'ayant posé des soucis avec Rails).
Un autre point particulièrement soigné de Django, ce sont les pages d'erreurs. Du bonheur ! Contrairement à celles de Rails, elles permettent réellement d'aider à débugger. Ça dépasse largement le cadre de la page d'erreur. Rails devrait s'en inspirer.
La suite au prochain épisode.
