Un Electron Libre...

Début de résultats sur ma petite pause dans la réalisation du projet Atome avec Django : J'ai cherché à jouer avec Symfony et non, décidément, je ne m'y fais pas.

J'ai reproduit le tutoriel en l'adaptant un peu pour être plus conforme au projet Atome et bof :

• Je trouve que la documentation de Symfony est moins exhaustive que celle de Django. Suffit de voir la doc des modèles pour cela : Symfony model vs Django - model api
• Pour produire un résultat équivalent ou presque, je dois écrire beaucoup plus de code coté symfony que du coté de django,
• J'ai toujours autant de mal avec la syntaxe de PHP avec ces ::, ->, etc. La base de PHP en fait peut être un langage facile à prendre en main mais pour le moment, je trouve python plus simple
• Faut faire un nombre de commande considérable avant d'avoir qqc (symfony propel-build-model, symfony propel-build-sql, symfony propel-insert-sql, symfony propel-generate-crud). A contrario, cela donne peut être à Symfony plus de souplesse et lui permet peut être de construire une interface d'admin plus souple que celle fournit nativement dans Django (mais j'avoue ne pas avoir trop creuser ce point).

Donc après un rapide test, je mets Symfony de coté et je le laisse à mes camarades de bac à sable .

Reste rails, ce qui présuppose que j'achère la dernière version du bouquin, car contrairement à Django, il n'y a pas de véritable documentation en ligne (ou à toi cher lecteur de me montrer où elle est...)

Suite au prochain épisode !

C'est encore la faute à Niko qui me demandait pourquoi je n'étais pas parti sur un framework PHP ou sur (Ruby on) Rails pour le projet Atome.

Mes raisons sont assez simples :

• C'est en lisant "Apprendre à programmer en python" que j'ai découvert python et compris le fonctionnement de la programmation orienté objet et les notions de classes, méthodes, etc.
• Python est un langage universel dans le sens où on peut aussi bien faire des scripts batch, que des applications graphiques ou du développement web (contrairement à PHP, même s'il y a un php-cli et php-gtk)
• David m'avait bien vendu python lors d'échanges par mail,
• le modèle objet de PHP reste obscure pour moi avec ces -> et ces $this

Maintenant que j'ai un début de blog qui tourne sous django (comprendre je peux créer/modifier/supprimer des billets, les assigner à des catégories et/ou tags, lister les catégories/tags et lister les billets d'une catégorie ou d'un tag), je me demande si je ne vais pas m'occtroyer une petite pause dans mon développement (pourtant, ce matin dans le train, je me suis noté 25 tâches à faire pour terminer ce projet ).

Cette pause consisterait à recréer ce que j'ai fait pour le moment sous Django sous d'autres frameworks pour voir ce que j'en pense en vrai

La liste des prétendants pourrait être la suivante :

• Framework PHP : Symfony, mais c'est peut être sortir un tank pour pas grand chose...
• Framework Ruby : Rails

Brièvement, le projet Atome a pour objectif de permettre d'avoir en un seul et unique endroit, un espace "blog" et un espace "tutoriel" avec tout ce qui va bien (commentaire threadé, tags, catégories, flux rss/atom, trackbacks, pings, coloration syntaxique, éditeur riche (pas forcément wysiwyg...), urls propres, etc).

et toi cher lecteur, qu'en penses-tu de cette idée ? que ferais-tu à ma place ?

Dans Django, il est possible de définir les urls à différents endroits :

• au niveau du projet : dans monprojet/urls.py
• au niveau de chaque application : dans monprojet/monapplication/urls.py

Solution 1 : vous stockez les urls au niveau du projet :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
    (r'^app/$', 'monprojet.monapplication.views.index'),
    (r'^app/page', 'monprojet.monapplication.views.page'),
)

Solution 2 : au niveau de chaque application :

Dans monprojet/urls.py :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
    (r'^app/', include('monprojet.monapplication.urls')),
)

et dans monprojet/monapplication/urls.py - attention à bien définir un chemin relatif (voir plus bas pour plus d'explications) :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^$', 'monprojet.monapplication.views.index'),
    (r'^page', 'monprojet.monapplication.views.page'),
)

Vous pouvez même simplifier ce dernier élément de la façon suivante :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('monprojet.monapplication',
    (r'^$', 'views.index'),
    (r'^page', 'views.page'),
)

Pour le contenu de monprojet/monapplication/urls.py, attention à ne pas faire apparaître une deuxième fois le chemin, comme on pourrait le croire :

from django.conf.urls.defaults import *
 
urlpatterns = patterns('',
    (r'^app/$', 'monprojet.monapplication.views.index'),
    (r'^app/page', 'monprojet.monapplication.views.page'),
)

Faute de quoi, django vous renverra une erreur 404 si vous appelez http://www.domain.tld/app/ car il cherchera le motif http://www.domain.tld/app/app/. Le premier "app" est en fait déjà définit dans monprojet/urls.py et le second dans monprojet/monapplication/urls.py.

En savoir plus : http://www.djangoproject.com/documentation/url_dispatch/

Ce jour, dans le RER, en attendant mon train, j'étais en train de continuer ma découverte du framewok Django. Je me disais "quel dommage de pas avoir de connexion internet, je n'ai aucune doc et c'est donc dur de pouvoir avancer sur la découverte de django..." A ce moment là un lien "Documentation" dans l'admin attire mon oeil. Je clique dessus et là : rien car il me manque le paquet docutils comme la page l'indique si bien.

En revenant chez moi, je m'empresse donc de faire :

geshi bash
sudo apt-get install python-docutils

Je relance webrick et me rend sur la page http://localhost:8000/admin/doc/ et là : que du bonheur !

Vous accédez à la doc de django (tag, filtes, vues, etc), ainsi qu'à une vision de vos modèles. Vous voyez ainsi tous vos modèles avec une description du type que vous avez défini. Cette représentation tient même compte des clés étrangères donc du coup, voyant le lien entre mon model "post" et "comment", il me propose des fonctionnalités croisées (lister tous les comments d'un post, etc).

Génial, non ?

Je viens de finir la partie 1 et la partie 2 du tutoriel de Django.

Premières impressions à chaud :

• Les possibilités de l'interface d'admin sont impressionnantes - il va falloir apprendre cette page sur les modèles pour en profiter...
• Ils auraient pu trouver plus fun comme tutoriel qu'une application de sondage
• Le livre sur Ruby on rails est nettement plus pédagogique et clair, c'est pour le moment le grand défaut que je fais à django...
• Suivre le tutoriel me permet de me familiariser avec python mais va falloir que je fasse les exercices de "Apprendre à programmer avec python" pour manipuler cela de façon plus simple et intuitive...