Lors du dernier petit-déjeuner Clever Age que j'ai animé sur les frameworks PHP, j'ai effectué une démonstration des fonctionnalités de génération de back-office existantes dans Symfony : la plupart des gens présents - pour la plupart découvrant la notion même de framework - ont été très impressionnés par la facilité déconcertante avec laquelle il était possible de développer une application complète en très peu de temps et d'étapes techniques grâce au générateur d'admin...
Personnellement, je suis tellement habitué à travailler avec de tels outils désormais que j'oublie parfois comme la vie est plus difficile sans eux... Je vais donc faire une démonstration afin que chacun puisse se faire son idée, sur sa propre machine 
Pour faire très original, on va créer une petite application sommaire de gestion de weblog, doté des fonctionnalités suivantes :
- Un auteur par billet
- Billets multi-catégoriques (on pourrait aussi parler de tags)
- Commentaires pour chaque billet
L'avantage est que la plupart des frameworks web proposent ce type de tutoriaux, donc ainsi vous pourrez plus aisément comparer
Installation de Symfony
Je vous renvoie à la documentation officielle ou à ce tutoriel pour installer Symfony sur votre machine et configurer un vhost apache pour votre nouveau projet. On partira sur la version 1.0.2, soit la dernière version stable disponible à l'heure où sont écrites ces quelques lignes.
Création d'un nouveau projet
Imaginons que votre projet soit créé dans /var/www :
$ sudo -s
# cd /var/www
# mkdir sftest && cd sftest
# symfony init-project sftest
Note: Si la page web par défaut du projet n'affiche pas d'images, il se peut que votre vhost ne trouve pas les éléments médias génériques de Symfony ; dans ce cas, un lien symbolique comme ci-dessous devrait régler le problème :
# ln -s /usr/share/php/data/symfony/web/sf web/sf
Note : Vous pourriez tout autant utiliser un alias apache dans votre vhost.
Créons maintenant nos deux applications front et back qui recevront le front-office et la console d'administration de notre projet :
# symfony init-app front
# symfony init-app back
On crée une base de données dédiée au projet :
# mysql -uroot -p
> CREATE DATABASE sftest CHARACTER SET utf8 COLLATE utf8_general_ci;
> GRANT ALL ON sftest.* TO sftest@localhost IDENTIFIED BY '1234567'
> FLUSH PRIVILEGES;
> \q
Configuration de l'accès à la base de données
D'abord, on renseigne notre DSN MySQL dans le fichier config/databases.yml :
all:
propel:
class: sfPropelDatabase
param:
dsn: mysql://sftest:1234567@localhost/sftest
On fait la même chose pour Propel, dans le fichier config/propel.ini :
propel.database.url = mysql://sftest:1234567@localhost/sftest
Configuration du modèle de données
On crée le schéma de base notre de données, dans le fichier config/schema.yml :
propel:
blog_authors:
_attributes: { phpName: Author }
id:
name: varchar(255)
email: varchar(255)
blog_posts:
_attributes: { phpName: Post }
id:
title: varchar(255)
excerpt: longvarchar
body: longvarchar
author_id:
created_at:
updated_at:
blog_comments:
_attributes: { phpName: Comment }
id:
post_id:
author: varchar(255)
email: varchar(255)
site: varchar(255)
content: longvarchar
created_at:
blog_sections:
_attributes: { phpName: Section }
id:
name: varchar(255)
blog_posts_sections:
_attributes: { phpName: PostSection }
id:
post_id:
section_id:
Il y a beaucoup de magie dans la syntaxe de ce fichier. Retenez juste que les champs id, *_id et *_at sont nommés en vertus de conventions Symfony pour gérer automatiquement clés primaires, clés étrangères et les champs de type DATETIME.
Création d'un jeu de données de test
De même et parce qu'on est des gens sérieux (mais surtout parceque c'est pratique), on crée d'emblée un jeu de données de test (ou fixtures), dans un nouveau fichier data/fixtures/data.yml :
Author:
NiKo:
name: NiKo
email: tepafou@fai.com
Post:
FirstPost:
title: Mon premier post !
excerpt: Un premier billet prometteur...
body: >
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Integer
consectetuer congue diam. Sed eu enim. Cras fringilla, erat et pretium
tincidunt, elit nibh imperdiet lectus, vel viverra erat velit in
metus. Ut ipsum ante, ornare luctus, hendrerit in, ultricies id, est.
author_id: NiKo
SecondPost:
title: Mon deuxième billet
excerpt: Un deuxième billet tout aussi savoureux.
body: >
Suspendisse potenti. Mauris id risus. Cras urna. Etiam vel enim nec
dui ultrices condimentum. Curabitur bibendum ultrices quam. Nulla
sodales risus eget nunc.
author_id: NiKo
Section:
Humeurs:
name: Humeurs
Geek:
name: Geek
Ubuntu:
name: Ubuntu
PostSection:
# First post categories
FirstPost_Humeurs:
post_id: FirstPost
section_id: Humeurs
FirstPost_Geek:
post_id: FirstPost
section_id: Geek
# Second post categories
SecondPost_Geek:
post_id: SecondPost
section_id: Geek
SecondPost_Geek:
post_id: SecondPost
section_id: Ubuntu
Comment:
Comment1:
post_id: FirstPost
author: Jean-Paul
email: "jp@fai.com"
site: "http://blog.jeanpaul.com"
content: Bravo, belle intervention.
Comment2:
post_id: SecondPost
author: Jean-Luc
email: "jl@fai.com"
site: "http://blog.jeanluc.org"
content: Exactement, vous avez raison.
Ceci fait, on va lancer la génération du fichier SQL et des classes représentant notre modèle, créer les tables physiquement dans notre base et insérer notre jeu de données de test :
# symfony propel-build-all-load back
Vous noterez qu'un seule ligne de commande est à appeller, ce qui simplifie grandement les phases de prototypage.
Note : En cas de modification profonde du modèle de données, il est vivement conseillé de vider le cache symfony :
# symfony cc
Ajout des méthodes __toString() aux objets de données
Afin d'avoir facilement un descripteur texte pour notre objet Author, nous allons implémenter une méthode __toString() dans sa classe associée située dans le fichier lib/model/Author.php :
class Author extends BaseAuthor
{
public function __toString()
{
return $this->getName();
}
}
Cette méthode retournera le contenu du champs name de l'enregistrement de la table blog_authors correspondant pour identifier l'objet PHP sous la forme d'une chaîne de caractère descriptive. Vous pouvez aussi adapter ce principe pour les objets Post et Section, par exemple.
Génération d'un back-office d'administration des billets
Maintenant, on va générer une interface d'administration de nos objets Post, accessible par un contrôleur /posts depuis notre application back :
# symfony propel-init-admin back posts Post
L'interface d'administration est maintenant accessible via /back_dev.php/posts derrière la racine de l'url de votre instance projet Symfony
C'est un peu sec par défaut et les sections associées aux billets du blog ne sont pas gérées, il nous faut donc adapter le fichier de configuration du générateur d'admin de Symfony pour ce module, situé dans le fichier apps/back/modules/posts/config/generator.yml :
generator:
class: sfPropelAdminGenerator
param:
model_class: Post
theme: default
# Customisation des colones de la vue en liste, lien d'édition sur le titre
list:
display: [=title, excerpt, Author, created_at, updated_at]
# Customisation du formulaire d'ajout/édition
edit:
# Champs personnalisés
fields:
# Création d'un champs d'administration des sections associées
post_sections: { type: admin_check_list, params: through_class=PostSection }
# Spécification des champs de formulaire à afficher
display: [author_id, title, excerpt, body, post_sections]
Un raffraîchissement des interfaces en mode développement (en appellant le contrôleur back_dev.php dans l'url) affichera nos interfaces modifiées en conséquences. Si vous utilisez le contrôleur de production (/back.php), n'oubliez pas de vider le cache symfony pour visualiser vos modifications :
# symfony cc
On reproduira exactement la même opération pour nos autres objets à administrer (Author, Comment et Section):
# symfony propel-init-admin back authors Author
# symfony propel-init-admin back sections Section
# symfony propel-init-admin back comments Comment
Voila, une vingtaine de minutes nous auront suffit pour générer une application en ligne relativement complète. Il restera à gérer notamment :
Amusez-vous bien
