Gagnez du temps avec Symfony 1.0 et son générateur de back-office

NiKo — Sat, 28 Apr 2007 16:26:00 +0200

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 :

la sécurité d'accès
l'affichage des commentaires pour chaque billet
l'affichage en front office des billets
améliorer l'ergonomie et la présentation de ce back-office, par exemple en surchargeant ses éléments générés (documentation complète)

Amusez-vous bien

Ce billet intitulé Gagnez du temps avec Symfony 1.0 et son générateur de back-office a été rédigé par Nicolas Perriault et publié sur le blog Prendre un Café sous licence Creative Commons BY-NC-SA.

Prendre un Café - Tag - scaffolding