Pour le listing de ces zones j’ai donc choisi d’utiliser un plugin jQuery : treeTable. Comme son nom l’indique ce plugin va nous permettre une organisation d’un arbre dans une table HTML. Il faut indiquer en « id » de la balise
de notre tableau un identifiant de notre objet (ex: id= »node-1″) et à l’attribut « class » on signale de qui le noeud est l’enfant (ex: child-of-node-1 sera le fils du noeud 1).

  <div class="content-box-content">
    <table id="tree">
      <tbody>
        <?php foreach ($areas() as $area) : ?>
        <?php $parent = $area->getNode()->getParent() ?>
        <tr id="node-<?php echo $area->getId() ?>" <?php echo $parent ? 'class="child-of-node-'.$parent->getId().'"' : '' ?>>
          <td><?php echo $area->getName() ?></td>
          <td>
            <?php echo link_to(__('module_area_list_action_add_children'), 'area_new', $area->getType(), array('query_string' => 'parent_id='.$area->getId())) ?>
          </td>
          <td>
            <?php echo link_to(__('text_action_delete'), '@area_delete?id='.$area->getId(), array('method' => 'delete', 'confirm' => __('text_action_delete_confirm'))) ?>
          </td>
        </tr>
        <?php endforeach ?>
      </tbody>
    </table>
  </div>

Voici le résultat :

Le rendu correspond à ce que souhaite mon client, lorsque l’on clique sur une branche, par exemple Afrique ou Europe les lignes suivantes se déplient et laissent apparaitre les enfants. Tout va pour le mieux dans le meilleur des mondes, simplement quand on regarde de plus près on s’aperçoit que pour un listing de simplement 12 zones je fais 29 requêtes, que va t’il se passer lorsque je vais avoir toutes mes zones renseignées, la réponse est : +700 requêtes. Le souci vient de la méthode getNode()->getParent() qui exécute une nouvelle requête à chaque appel. En effet pour lier une ligne à son parent j’ai besoin de connaître l’ID du père.

Pour remédier à cela je vais donc utiliser l’Hydratation hiérarchisée, que l’on peut créer à l’aide d’une Doctrine_Query qu’on exécutera comme suit :

Doctrine_Core::getTable('Area')->
   createQuery('a')
  execute(array(), Doctrine_Core::HYDRATE_RECORD_HIERARCHY);

Sinon on peut directement utiliser la méthode toHierarchy() sur notre collection, qui nous hydratera directement cette dernière. Chaque élément contenant alors des enfants aura une clé __children, qui n’est autre qu’un tableau des éléments enfants.

Je vais donc remplacer mon code et utiliser un helper pour le rendu d’une ligne ce qui permettra de faire de la récursivité plus facilement dans mon code.

Je crée donc l’helper suivant :

// apps/backend/lib/helper/AreaHierarchyHelper.php
 
<?php
 
/**
 * Permet l'affichage en arbre dans le listing des zones
 *
 * @param Area $area
 * @param int $parent
 * @return string
 */
function render_row($area, $parent = null)
{
 
  // Formatage du HTML
  $html = sprintf('
<tr id="node-%s"%s>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
  <td>%s</td>
</tr>',
      $area->getid(), (null === $parent ? '' : sprintf(' class="child-of-node-%s"', $parent)),
      $area->getName(),
      'ID : '.$area->getId(),
      link_to(__('module_area_list_action_add_children'), 'area_new', $area->getType(), array('query_string' => 'parent_id='.$area->getId())),
      link_to(__('text_action_edit'), 'area_edit', $area, array('class' => 'area-edit')),
      link_to(__('text_action_delete'), '@area_delete?id='.$area->getId(), array('method' => 'delete', 'confirm' => __('text_action_delete_confirm'))));
 
  // Récursivité pour créer les lignes des fils
  foreach ($area->get('__children') as $child)
  {
    $html .= render_row($child, $area->getid());
  }
 
  return $html;
}

Désormais sur ma page, il me suffit de charger mon helper et d’écrire le code suivant :

<?php use_helper('AreaHierarchy') ?>
 
<div class="content-box">
  <div class="content-box-header">
  </div>
  <div class="content-box-content">
    <table id="tree">
      <tbody>
        <?php foreach ($areas()->toHierarchy() as $area) : ?>
          <?php echo render_row($area) ?>
        <?php endforeach ?>
      </tbody>
    </table>
  </div>
</div>

Le résultat est exactement le même au niveau de l’affichage en revanche je passe désormais à 5 requêtes et sur les données définitives, j’obtiens toujours 5 requêtes et ce quelque soit le nombre de résultat dans ma collection. J’ai donc bénéficié des avantages de Doctrine et surtout des Doctrine_Hydrator pour diminuer le nombre de requêtes.

Le behavior donne les fonctionnalités, le plugin donne le modèle et l’affichage ainsi que les actions (listing des commentaires, formulaire d’ajout de commentaire, …)

Je me suis basé sur le behavior Doctrine Taggable fourni à l’origine pour réaliser ceci.

Le behavior et le plugin ne sont pas utilisable l’un sans l’autre.

télécharger les sources

Fourni par le behavior :

Le listener :

void postDelete(event) //supprime tous les commentaires liés lors de la suppression de l’objet les portant

Le template et ses méthodes :

void addComment(Comment) //ajoute le commentaire à l’objet

void deleteComments() //supprime tous les commentaires reliés à l’objet

Doctrine_Collection findComments(array $params, array $orders) //retourne tous les commentaires liés à l’objet, respectant les paramètres du tableau params, et classés successivement dans les ordres donnés par le tableau orders

int getNbComments() //retourne le nombre de commentaires liés à l’objet

CommentForm getCommentForm()

Fourni par le plugin :

La classe Comment :

getParent() pour récupérer l’objet porteur du commentaire

La classe CommentTable :

getCommentsFilteredQuery($params, $orders) pour récupérer une requête permettant de retrouver une collection de commentaires selon certains paramètres, et en respectant une suite d’ordres

getUnmoderatedCommentsQuery() pour récupérer une requête permettant de retrouver la collection des commentaires non modérés

getSpamCommentsQuery() pour récupérer la collection des commentaires classés spam
Le modèle de données :

Comment:
  tableName: sf_comment
 
  actAs: [Timestampable]
 
  columns:
    user_id:
      type: integer(4)
 
    #nom de l'auteur
    author_name:
      type: string(255)
      default: Anonyme
    #email de l'auter
    author_mail:
      type: string(255)
    #site web de l'auteur
    author_website:
      type: string(255)
 
    #texte du commentaire
    text:
      type: clob
 
    #id de l'objet porteur du commentaire
    parent_id:
      type: integer
    #classe de l'objet porteur du commentaire
    parent_class_name:
      type: string(255)
 
    #publié ?
    is_published:
      type: boolean
      notnull: true
      default: true
    #modéré ?
    is_moderated:
      type: boolean
      notnull: true
      default: false
    #est un spam ?
    is_spam:
      type: boolean
      notnull: true
      default: false
 
  relations:
    sfGuardUser:
      type: one
      foreignType: many
      local: user_id
      foreign: id
      foreignAlias: Comments

La technique pour relier un objet à cette table Comment est d’utiliser 2 champs spéciaux : parent_class_name et parent_id qui contiennent le nom de la classe ainsi que l’identifiant en base de l’objet porteur du commentaire.

De cette manière, on perd en partie l’aspect relationnel de la base, mais on allège énormément les requêtes de listing (derniers commentaires toutes catégories confondues, commentaires reliés à un objet, reliés à un type d’objet, …).
Comment ça marche :

télécharger les sources
Avant de commencer, il faut évidemment copié les sources du plugin dans le répertoire plugin/ de votre projet, puis :

php symfony plugin:publish-assets

Tout d’abord, il faut activer le module dans les settings, en l’ajoutant comme ceci :

all:
  .settings:
    enabled_modules: [default, sfGuardAuth, sfGuardUser, comment]

Ensuite dans le schema.yml du projet, il faut spécifier le behavior sur l’objet :

Message:
  actAs:
    Timestampable: ~
    Commentable: ~
  columns:
    …

A partir de là, on utilisera les fonctions et méthodes vues plus haut (fournies par le template).

Le plugin fournit des partials pour l’affichage par défaut, personnalisable via les noms de classes et id passables en paramètres (toutes les classes et id sont définies par défaut si pas d’options) :

Partial show_comment, paramètres :
$comment : le message à afficher
$options : les options spécifiques pour css personnalisé
show_comment_class → conteneur global
infos_class → entete (auteur, date et heure)
author_name_class → auteur
time_and_date_class → date et heure
date_class → date
time_class → heure
text_class → corps du commentaire

Partial comments_list, paramètres : (boucle sur le partial show_comment, donc passer en parametre les options pour le show_comment)
$comments : la liste des messages à afficher
$options : les options spécifiques pour css personnalisé
list_comment_class : classe de la div conteneur
list_comment_id : id de la div conteneur

Partial form_comment, paramètres :
$form : le formulaire
$action : l’action du formulaire, définie par défaut
$options : les options spécifiques pour css personnalisé
id → id du formulaire
class → classe du formulaire

Partial ajax_script, paramètres : script jquery permettant de valider le formulaire en ajax
$form : le formulaire

Partial ajax_form_comment, paramètres : le formulaire et le script ajax

Exemple d’utilisation :

  <!-- // liste des commentaires du message -->
  <?php include_partial('comment/comments_list', array('comments'=>$message->findComments(array(), array('created_at DESC')), 'options'=>array())) ?>
 
  <!-- // formulaire d'ajout de commentaire -->
  <div id="form<?php echo $message->getId() ?>">
    <h2>Postez votre commentaire :</h2>
    <?php include_partial('comment/ajax_form_comment', array('form'=>$message->getCommentForm())) ?>
  </div>

Vous aurez noté qu’on ne parle pas encore de l’administration dans ce post, dans les publications à venir je vous parlerai d’abord du backend pour les commentaires, puis de la réalisation d’un behavior étape par étape.

Il comporte des formulaires d’identification et d’inscription très basique, mais son principal point fort est la gestion des droits associés aux utilisateurs, la possibilité de gérer des groupes le tout générant automatiquement les crédentials qui va permettre de sécuriser l’application de manière très simple.

Je ne reviendrai pas sur la gestion des crédentials qui est très bien expliquée dans le Jobeet #13.

De même pour l’installation. Le readme est très bien fait et explique très clairement comment faire.

Le modèle de données

Le modèle de données du plugin comporte la table des Utilisateurs, des Groupes et des Permissions ainsi que les tables d’associations entre Utilisateurs/Permissions, Groupes/Permissions et Utilsateurs/Groupes.

Ce sont les permissions attribuées à un utilisateur (directement ou par ses groupes) qui déterminent les crédentials qu’il aura une fois logué (C’est le nom de la permission qui sera le nom du crédential).

Pour illustrer tout ca, on va voir un petit exemple.

On prends une structure simple, avec 2 groupes et 3 permissions.
Les permissions de Lecture, Ecriture et Téléchargement (même si la loi Hadopie a été votée ^^).
Les groupes Admin qui a tous les droits et Membre qui n’a que le droit de lecture.

 
sfGuardPermission:
  pLecture:
    name: lecture
  pEcriture:
    name: ecriture
  pTelegargement:
    name: telechargement
 
sfGuardGroup:
  gAdmin:
    name: admin
  gMembre:
    name: membre
 
sfGuardGroupPermission:
  gp1:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pLecture
  gp2:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pEcriture
  gp3:
    sfGuardGroup:      gAdmin
    sfGuardPermission: pTelegargement
  gp4:
    sfGuardGroup:      gMembre
    sfGuardPermission: pLecture

Et 3 utilisateurs : Toto, Titi et Tata à qui on va définir des droits différents.

- Toto sera dans le groupe admin, il aura ainsi tout les droits.
- Titi et Tata seront dans le groupe Membre et auront ainsi seulement le droit de Lecture.
- Titi a en plus le droit de téléchargement.

Ce qui se traduit en fixture comme ceci :

 
sfGuardUser:
  Toto:
    username: toto
    password: t0t0
  Titi:
    username: titi
    password: t1t1
  Tata:
    username: tata
    password: t4t4
 
sfGuardUserGroup:
  ug1:
    sfGuardUser:  Toto
    sfGuardGroup: gAdmin
  ug2:
    sfGuardUser:  Titi
    sfGuardGroup: gMembre
  ug3:
    sfGuardUser:  Tata
    sfGuardGroup: gMembre
 
sfGuardUserPermission:
  up1:
    sfGuardUser:       Titi
    sfGuardPermission: pTelegargement

Dans un module lambda, on peut donc très facilement sécuriser nos pages comme suit.

/module/config/security.yml

secure:
  is_secure:   on
 
telechargement:
  is_secure:   on
  credentials: [lecture, telechargement]
 
default:
  is_secure:   off

La page secure nécessite que l’utilisateur soit connecté mais il n’y a aucune restriction de crédential. Les 3 utilisateur, une fois logés, pourront y accéder.

La page téléchargement nécessite 2 permissions lecture et téléchargement. Seuls Toto et Titi y auront accès. Tata sera redirigé automatiquement vers la page d’erreur de permissions.

La redirection après l’authentification.

L’authentification est gérée par le plugin, il suffit d’envoyer l’utilisateur vers la route @sf_guard_signin.

Une fois l’authentification effectuée, le script redirige l’utilisateur. Par défaut l’utilisateur est redirigé vers le HTTP_REFERER.

Heureusement on peut aussi déterminer une route vers laquelle on veut être redirigé après l’authentification de plusieurs manières.

Premièrement via des variable du app.yml

all:
  sf_guard_plugin:
    success_signin_url:      @my_route?param=value
    success_signout_url:     module/action

Autre méthode qui consiste à utiliser le comportement par défaut de redirection vers le referer, mais en utilisant la méthode setReferer() de la classe sfGuardSecurityUser.

<?php
class moduleActions extends sfActions
{
  ...
  public function executeAction(sfWebRequest $request)
  {
    ...
    $this->getUser()->setReferer('@my_route');
    $this->redirect('@sf_guard_signin');
  }
}

L’ordre de priorité est :
- la variable du fichier app.yml
- le getReferer() du GuardUser
- le HTTP_REFERER

Connecter automatiquement un utilisateur

Il est possible de connecter automatiquement un utilisateur grâce à la méthode signin() à la quelle on doit passer une instance de sfGuardUser.

Par exemple dans une action quelconque :

<?php
class moduleActions extends sfActions
{
  ...
  public function executeAction(sfWebRequest $request)
  {
    ...
    $utilisateur = Doctrine::getTable('sfGuardUser')->findOneByUsername('toto');
    $this->getUser()->signin($utilisateur);
    ...
  }
}

Associer un ou plusieurs groupes à un utilisateur

On a vu au début de l’article comment associer des groupes aux utilisateurs par le fixture.

On va voir ici comment le faire en php.

Par exemple si on avait à le faire dans le script d’inscription et qu’on veulait associer automatiquement le groupe membre aux utilisateurs qui s’inscrivent.

 
public function executeInscription(sfWebRequest $request)
{
  $this->form = new sfGuardUserFormRegister();
  // la classe de formulaire sfGuardUserFormRegister n'existe pas dans le plugin par defaut
  // je la mets en annexe à la fin de l'article
 
  if($request->isMethod('post'))
  {
    $this->form->bind($request->getParameter($this->form->getName()));
 
    if($this->form->isValid())
    {
      $permission = Doctrine::getTable('sfGuardGroup')->findOneByName('membre');
 
      $utilisateur = $this->form->getObject();
      $utilisateur['permissions'][] = $permission;
      $utilisateur->save();
 
      $this->getUser()->signIn($utilisateur);
      $this->redirect('@homepage');
    }
  }
}

Annexe

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

 
/**
 * formulaire d'inscription
 *
 * @package    form
 * @subpackage sfGuardUser
 * @author     Lexik
 * @version    SVN: $Id: sfDoctrineFormTemplate.php 6174 2007-11-27 06:22:40Z fabien $
 */
class sfGuardUserFormRegister extends PluginsfGuardUserForm
{
 
  public function configure()
  {
    unset(
      $this['groups_list'],
      $this['permissions_list'],
      $this['algorithm'],
      $this['salt'],
      $this['is_active'],
      $this['is_super_admin'],
      $this['last_login'],
      $this['created_at'],
      $this['updated_at']
    );
 
    $this->widgetSchema['password']     = new sfWidgetFormInputPassword();
    $this->widgetSchema['password_bis'] = new sfWidgetFormInputPassword();
 
    $this->widgetSchema->setLabels(array(
      'username'     => 'Email* :',
      'password'     => 'Mot de passe* :',
      'password_bis' => 'Confirmation* :'
    ));
 
    $this->validatorSchema['username']     = new sfValidatorEmail(array('required' => true), array('invalid' => 'Cet email n\'est pas valide.', 'required' => 'Champ obligatoire.'));
    $this->validatorSchema['password']     = new sfValidatorString(array('required' => true, 'min_length' => 6), array('min_length' => '"%value%" est trop court (%min_length% lettres minimum).', 'required' => 'Champ obligatoire.'));
    $this->validatorSchema['password_bis'] = new sfValidatorString(array('required' => true, 'min_length' => 6), array('min_length' => '"%value%" est trop court (%min_length% lettres minimum).', 'required' => 'Champ obligatoire.'));
 
    $this->mergePostValidator(new sfValidatorSchemaCompare(
      'password',
      sfValidatorSchemaCompare::EQUAL,
      'password_bis',
      array(),
      array('invalid' => 'Les champs doivent être identiques.')
    ));
  }
 
}

Un exemple ici : j’ai des utilisateurs, avec la table User, mais j’ai aussi une table sfGuardUser.

Ma table User contient les infos globales de mes utilisateurs, alors que la table sfGuardUser contient les informations d’identification et permet également de récupérer les infos sur les permissions, les groupes, etc.

Voilà le problème : j’ai dans le listing de mes utilisateurs ajouté la colonne « Administrateur ? », indiquant si l’utilisateur est admin ou non (vous l’aurez compris…), pour cela il m’a suffit de rajouter la méthode getIsAdmin() dans ma classe User.class.php (lib/model/doctrine/User.class.php), et le champs is_admin dans le generator.yml de mon module user dans le backend (apps/backend/modules/user/config/generator.yml). (cf jobeet n°12)

Pour le filter le problème est un tout petit peu plus complexe : il n’utilise pas la classe pour filtrer l’affichage, et n’utilisera donc pas la méthode getIsAdmin().

Pourquoi ?

Par ce qu’il ne fait que générer une requete Doctrine_Query executée dans l’action.

Il y’aura donc ici 3 choses à faire :

1. ajouter le champs is_admin dans le formulaire du filter
2. surcharger la méthode getFields() (sert à récupérer les valeurs du formulaire)
3. ajouter la méthode qui modifie la requête

1) Ajout du champs is_admin (lib/form/filter/doctrine/UserFormFilter.class.php)
Le formulaire du filtre n’est rien de mieux qu’un formulaire sfFormFilter, on a donc déjà vu comment ça marche

    $this->validatorSchema['is_admin'] = new sfValidatorBoolean(array('required' => false), array());
    $this->widgetSchema['is_admin'] = new sfWidgetFormSelect(array(
      'choices' => array('' => '', true => 'oui', false => 'non')
      ));

Pensez aussi à créer le label correspondant.

2) Surcharge de getFields() (lib/form/filter/doctrine/UserFormFilter.class.php)

  public function getFields()
  {
    return array_merge(array('is_admin' => 'IsAdmin'), parent::getFields());
  }

3) Ajout de la méthode de modification de la requête :

  public function addIsAdminColumnQuery(Doctrine_Query $q, $field,$value)
  {
    if($value) //je cherche à trouver les admins
    {
      $a = $q->getRootAlias();
      $q->innerJoin($a . '.sfGuardUser u')
        ->innerJoin('u.sfGuardUserPermission up')
        ->innerJoin('up.sfGuardPermission p')
        ->andWhere('p.name = ?', 'admin');
    }
 
    if(!$value) //si je cherche les non admins
    {
      $a = $q->getRootAlias();
      $q->innerJoin($a . '.sfGuardUser u')
        ->innerJoin('u.sfGuardUserPermission up')
        ->innerJoin('up.sfGuardPermission p')
        ->andWhere('p.name = ?', 'member');
    }
    return $q;
  }

Essayons de voir le plan général :

- la méthode à ajouter doit s’appeler add*nom de la colonne*ColumnQuery
- elle prend en paramètres :

- la requête déjà défini par les autres champs du filtre, si aucun champs n’est renseigné elle correspond à la
requête récupérant tous les objets en question (ici les utilisateurs)

- le nom du champs en question

- la valeur entrée dans le formulaire filter.

A vous de modifier ensuite la requête passée en paramètre pour filtrer vos résultats.
Et voilà !!

Le schema.yml est généralement trop vite oublié. C’est facile à faire, ça génère la base sans trop se poser de questions, et puis on l’oublie… Alors que le schema.yml est certainement le fichier le plus important d’une application Symfony.

Je vais donc essayer de regrouper dans ce post les questions auxquelles on répond généralement par « Regardes dans ton schema.yml » où « Comment est ce que tu l’as défini dans ton schema.yml ? ».

Notamment au niveau des définitions des relations et les méthodes magiques qui en découlent.

Tout d’abord un petit bookmark des pages à lire et à relire de la documentation doctrine.

• Les types de colonnes
• Les relations
• Les data validations
• Les behaviors

(Personnellement je trouve que la documentation Doctrine est très bien faite. Les exemples omniprésent et la rendent très explicite, même pour un anglophobe.)

Pour ce post j’ai fait le schema.yml d’une application lambda. On a des utilisateurs, des groupes, la relation n:n entre les deux. Et pour rajouter une petite relation 1:n les utilisateurs ont des photos. (original non?)

J’ai utilisé des behaviors Timestampable et Sluggable.
Dans les types j’en ai profité pour tester le Enum que je n’utilisais pas jusqu’à présent, mais je pense que dans un avenir proche je vais m’en servir beaucoup plus
Pareil dans les data validation le « email: true » sur le champ email et le « past: true » sur la date de naissance sont assez énormes et permettent d’avoir déjà les validators adéquats dans les classes formulaires.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

Utilisateur:
  tableName:        test_utilisateur
  actAs:
    Timestampable:  ~
    Sluggable:
      unique:       true
      fields:       [nom,prenom]
      canUpdate:    true
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    sexe:           { type: enum, values: ['','Homme','Femme'], default: 'Homme' }
    nom:            { type: string(255) }
    prenom:         { type: string(255) }
    date_naissance: { type: date, past: true }
    email:          { type: string(255), notnull: true, unique: true, email: true }
  relations:
    Groupes:
      class:        Groupe
      refClass:     Membre
      local:        utilisateur_id
      foreign:      groupe_id
 
 
Photo:
  tableName:        test_photo
  actAs:
    Timestampable:  ~
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    fichier:        { type: string(255), notnull: true }
    utilisateur_id: { type: integer(4), unsigned: true, primary: true }
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE
 
 
Membre:
  tableName:        test_membre
  columns:
    utilisateur_id: { type: integer(4), unsigned: true, primary: true }
    groupe_id:      { type: integer(4), unsigned: true, primary: true }
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Groupe:
  tableName:        test_groupe
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }
    nom:            { type: string(255), notnull: true }
  relations:
    Utilisateurs:
 
      class:        Utilisateur
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id

La convention de nommage

Le nom des objets : Le plus court et le plus explicite possible. En CamelCase avec la première lettre en majuscule et au singulier. Pourquoi la 1er lettre en majuscule. Si la table a le même nom, ça permet de les dissocier facilement pour éviter les ambiguïté, notamment dans la construction des requête en DQL.

Le nom des relations : Si possible, je donne le même nom que l’objet cible. Au singulier si on est sur une relation N:1 ou 1:1 et au pluriel quand on est sur une relation 1:N ou N:N (généralement les foreignAlias). La aussi la 1er lettre en majuscule est importante, car elle permet de conserver une syntaxe camelCase sur les accessers magiques.

Par exemple sur l’objet Photo :

Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id

L’accesseur magique sera :

$ma_photo->getUtilisateur();

Alors que si on appelle la relation en minuscule :

Photo:
  ...
  relations:
    utilisateur:
      local:        utilisateur_id
      foreign:      id

L’accesseur magique sera

$ma_photo->getutilisateur()

Et du coup on perd la syntaxe camelCase qui est généralisée dans tout le framework.
C’est du chipotage mais ca peut être source d’erreur bête qui fait perdre du temps.

Les TOC (Troubles Obsessionnels de Codage :p) ou Bonnes pratiques

Sur les relations 1:N et 1:1, je définie toute la relation dans l’objet qui possède la clé étrangère. Pour essayer de ne pas alourdir trop mon schema.yml et aussi par faignantise.

Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Photos
      onDelete:     CASCADE

Cette relation défini 2 méthodes magiques Photo::getUtilisateur() qui va retourner l’objet Utilisateur lié à la photo et Utilisateur::getPhotos() qui retourne une collection d’objets Photo liés à utilisateur.

Cette même relation peut se décrire aussi en la décomposant en 2 parties.

Utilisateur:
  ...
  relations:
    Photos:
      local:        id
      foreign:      utilisateur_id
      onDelete:     CASCADE
 
Photo:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      onDelete:     CASCADE

Les 2 méthodes marchent parfaitement et ont leurs avantages et leurs inconvénients.

Sur les relations N:N, je définie toute la relation dans la Classe de liaison, et sur les objets externes seulement la partie qui les concernent. Pour éviter les multiples redéfinitions.

Membre:
  ...
  relations:
    Utilisateur:
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Utilisateur:
  ...
  relations:
    Groupes:
      class:        Groupe
      refClass:     Membre
      local:        utilisateur_id
      foreign:      groupe_id
 
 
Groupe:
  ...
  relations:
    Utilisateurs:
      class:        Utilisateur
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id

Sur les objets, j’aime bien avoir des noms simples et explicites mais paradoxalement, j’aime bien préfixer mes tables dans la base de donnée. C’est pourquoi je redéfinie systématiquement le tableName des objets dans le schema.yml

Utilisateur:
  tableName:        test_utilisateur
  ...

Sur les objets l’id est généré automatiquement mais il est de type bigint(20) signé. Et là aussi, comme je suis un gros maniaque et que je n’aime pas avoir des id signé qui plus est en bigint. Je redéfini l’id en int signé.

Utilisateur:
  ...
  columns:
    id:             { type: integer(4), unsigned: true, primary: true, autoincrement: true }

Attention, il est possible de définir les relations à plusieurs endroits et de plusieurs manières différentes. Il faut essayer de se tenir à une méthodologie la plus stricte possible pour éviter des redéfinitions de relations.
Si il y a des redéfinitions, Symfony ne va pas forcement les détecter lors de la re-génération des classes et ça risque de ne pas fonctionner correctement.

Créer des relations avec les objets d’un plugin

On va prendre le cas de sfGuard qui est un des plugins les plus utilisés.

Petite chose à savoir. Quand on utilise sfGuard, l’id de l’objet sfGuardUser est un int signé. Si vous avez besoin de faire des jointures pensez bien à utiliser un integer(4).

(Le type des clé étrangère est très important et source de pas mal de problèmes.)

Si on voulait lier l’objet Photo à sfGuardUser il faudrait écrire quelque-chose comme :

Photo:
  ...
  columns:
    ...
    user_id: { type: integer(4) }
  relations:
    User:
      class:            sfGuardUser
      local:            user_id
      foreign:          id
      foreignAlias:     Photos
      onDelete:         CASCADE

Toujours dans l’hypothèse de l’intégration de sfGuard à la place de mon objet Utilisateur.
Pour les relations N:N, étant donné que l’on a pas accès au schema.yml de l’objet sfGuarduser avec lequel on va se lier. Il faut définir toutes les relations de manière externe.

Pour la relation avec les groupes ça donnerais :

Membre:
  ...
  relations:
    Utilisateur:
      class:        sfGuardUser
      local:        utilisateur_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
    Groupe:
      local:        groupe_id
      foreign:      id
      foreignAlias: Membres
      onDelete:     CASCADE
 
 
Groupe:
  ...
  relations:
    Utilisateurs:
      class:        sfGuardUser
      refClass:     Membre
      local:        groupe_id
      foreign:      utilisateur_id
      foreignAlias: Groupes

Méthodes magiques dans les objets

On a vu que les nom des relations et les foreignAlias engendraient des méthodes magiques qui permettent de remonter facilement les objets de la relation.
Si on reprends le schema.yml du début, la liste des méthodes magiques est la suivante :

 
//methodes magiques su l'objet Utilisateur
$utilisateur = new Utilisateur();
 
$utilisateur->getPhotos();
$utilisateur->getGroupes();
$utilisateur->getMembres();
 
//methodes magiques su l'objet Photo
$photo = new Photo();
 
$photo->getUtilisateur();
 
//methodes magiques su l'objet Membre
$membre = new Membre();
 
$membre->getUtilisateur();
$membre->getGroupe();
 
//methodes magiques su l'objet Groupe
$groupe = new Groupe();
 
$groupe->getMembres();
$groupe->getUtilisateurs();

Les getters et les setters sont aussi des méthodes magiques.

Il y a un petit piège à éviter si on veut surcharger un getter ou un setter.

Par exemple si on vaut surcharger le getter Nom de l’objet Utilisateur, on a tendance a vouloir écrire :

class UtilisateurTable extends Doctrine_Table
{
 
  public function getNom()
  {
    return parent::getNom();
  }
 
 
}

Et bien il ne faut pas ! Ça fait en fait une boucle infinie.
Il faut écrire :

class UtilisateurTable extends Doctrine_Table
{
 
  public function getNom()
  {
    return parent::_get('nom');
  }
 
 
}

Finders magiques dans les classes Table

Comme pour les getters, il y a deux finders magiques par champ dans la classe Table.
Un findByLechamp et un findOneByLechamp. Le premier qui retourne une collection d’objets (même s’il n’y en a qu’un) et le second qui renvoie un objet seul.

Par exemple:

 
$utilisateur = Doctrine::getTable('Utilisateur')->findOneByNom('Toto');

Le nombre de requêtes

Le nombre de requêtes effectuer en base peut rapidement devenir impressionnant.

Mais si on y regarde de plus prés ce sont souvent de petites requêtes.
On va voir comment jouer sur le nombre de requêtes générées avec un petit exemple.

Une action toute simple ou je récupère un objet Utilisateur par son slug.

<?php
 
//actions.class.php
class userActions extends sfActions
{
 
  public function executeIndex(sfWebRequest $request)
  {
    $this->test_utilisateur = Doctrine::getTable('Utilisateur')->findOneBySlug('teta-toto');
  }
 
}

Et la vue qui correspond

//indexSuccess.php
<p>Utilisateur : <?php echo $test_utilisateur->getPrenom() ?></p>
 
<p>Photos : <?php echo $test_utilisateur->getGroupes()->count() ?></p>
 
<ul>
<?php foreach($test_utilisateur->getPhotos() as $photo): ?>
  <li><?php echo $photo->getFichier() ?></li>
<?php endforeach; ?>
</ul>
 
<p>Groupes : <?php echo $test_utilisateur->getGroupes()->count() ?></p>
 
<ul>
<?php foreach($test_utilisateur->getGroupes() as $groupe): ?>
  <li><?php echo $groupe->getNom() ?></li>
<?php endforeach; ?>
</ul>

On vois que 3 requetes sont effectuées.

 
1. SELECT t.id AS t__id, t.sexe AS t__sexe, t.nom AS t__nom, t.prenom AS t__prenom, t.date_naissance AS t__date_naissance, t.email AS t__email, t.created_at AS t__created_at, t.updated_at AS t__updated_at, t.slug AS t__slug FROM test_utilisateur t WHERE t.slug = ? LIMIT 1 - (teta-toto )
 
2. SELECT t.id AS t__id, t.nom AS t__nom, t2.utilisateur_id AS t2__utilisateur_id, t2.groupe_id AS t2__groupe_id FROM test_groupe t LEFT JOIN test_membre t2 ON t.id = t2.groupe_id WHERE t2.utilisateur_id IN (?) - (1 )
 
3. SELECT t.id AS t__id, t.utilisateur_id AS t__utilisateur_id, t.fichier AS t__fichier, t.created_at AS t__created_at, t.updated_at AS t__updated_at FROM test_photo t WHERE t.utilisateur_id IN (?) - (1 )

La 1er requête est effectuée lors du findOneBySlug() dans l’action.
La seconde lors du getPhotos() dans la vue.
Et la derniere lors du getGroupes() dans la vue également.

On peut obtimiser le nombre de requete en forceant les jointures.

Pour le même code si on surcharge le finder findOneBySlug() en y rajoutant toutes les jointures

 
<?php
/**
 * /lib/model/doctrine/UtilisateurTable.class.php
 */
class UtilisateurTable extends Doctrine_Table
{
 
  public function findOneBySlug($slug)
  {
    $q = Doctrine_Query::create()
      ->from('Utilisateur u')
      ->leftJoin('u.Photos')
      ->leftJoin('u.Groupes')
      ->where('u.slug = ?', $slug);
 
    return $q->fetchOne();
  }
 
}

On obtiens le même résultat avec une seule requète

 
SELECT  t.id AS  t__id, t.sexe AS  t__sexe, t.nom AS  t__nom, t.prenom AS  t__prenom, t.date_naissance AS  t__date_naissance, t.email AS  t__email, t.created_at AS  t__created_at, t.updated_at AS  t__updated_at, t.slug AS  t__slug, t2.id AS  t2__id, t2.utilisateur_id AS  t2__utilisateur_id, t2.fichier AS  t2__fichier, t2.created_at AS  t2__created_at, t2.updated_at AS  t2__updated_at, t3.id AS  t3__id, t3.nom AS  t3__nom FROM test_utilisateur t LEFT JOIN test_photo t2 ON t.id = t2.utilisateur_id LEFT JOIN test_membre t4 ON t.id = t4.utilisateur_id LEFT JOIN test_groupe t3 ON t3.id = t4.groupe_id WHERE t.slug = ? - (teta-toto )

Il ne faut pas nonplus s’amuser a remonter la moitié de la base de donnée dans chaque requête, mais ça permet de mieu gérer la charge générée par les scripts.

Supprimer ou renommer un objet

Si on supprime ou qu’on renomme une classe, les classes générés ne sont pas nettoyées et il faut le faire « a la main » sinon, les objets sont toujours regénéré et les tables toujours présentes en base.

Par exemple si ou voulais supprimer l’objet Utilisateur parcequ’on a décidé de se servir de sfGuard pour gérer les utilisateurs.

Il faut supprimer :

• /lib/filter/doctrine/UtilisateurFormFilter.class
• /lib/filter/doctrine/base/BaseUtilisateurFormFilter.class.php
• /lib/form/doctrine/UtilisateurForm.class.php
• /lib/form/doctrine/base/BaseUtilisateurForm.class.php
• /lib/model/doctrine/Utilisateur.class.php
• /lib/model/doctrine/UtilisateurTable.class.php
• /lib/model/doctrine/base/Utilisateur.class.php

Merci a ceux qui ont eu le courage d’aller jusqu’au bout. J’avoue que je ne pensais pas faire un post aussi long à la base.
J’ai un peu tapé au kilomètre et je pense que je le remanierai d’ici quelques temps avec plus d’explications et beaucoup moins de fautes

http://forum.symfony-project.org/index.php/m/66906/?srch=tinymce+3+steps#msg_66906

En français et expliqué plus en détails, ça donne :

Intégrer Tiny MCE

• Télécharger et copier :
  http://tinymce.moxiecode.com/download.php
  dans :

  /web/js/tinyMCE

• Modifier ce fichier :

  /apps/backend/config/settings.yml

  ^?View Code YML

  all: .settings: sf_rich_text_js_dir: js/tinyMCE

Installer le plugin sfFormExtraPlugin:

symfony plugin:install sfFormExtraPlugin

Modifier le widget sfWidgetFormTextareaTinyMCE.class.php

Il faut modifier le plugin !

/plugins/sfFormExtraPlugin/lib/widget/sfWidgetFormTextareaTinyMCE.class.php

Fichier :

<?php
class sfWidgetFormTextareaTinyMCE extends sfWidgetFormTextarea
{
  protected function configure($options = array(), $attributes = array())
  {
    $this->addOption('theme', 'advanced');
    $this->addOption('width');
    $this->addOption('height');
    $this->addOption('config', '');
  }
  public function render($name, $value = null, $attributes = array(), $errors = array())
  {
    $attributes = array_merge($this->attributes, $attributes); 
    ...

Utilisation

Modifier ce fichier :

/lib/form/doctrine/ContenuForm.class.php

<?php
class ContenuForm extends BaseContenuForm
{
  public function configure()
  {
      $this->widgetSchema['texte'] =  new sfWidgetFormTextareaTinyMCE(
      array(
        'width'=>550,
        'height'=>350,
        'config'=>'theme_advanced_disable: "anchor,image,cleanup,help"',
        'theme'   =>  sfConfig::get('app_tinymce_theme','advanced'),
      ),
      array(
        'class'   =>  'tiny_mce'
      )
    );
    $js_path = sfConfig::get('sf_rich_text_js_dir') ? '/'.sfConfig::get('sf_rich_text_js_dir').'/tiny_mce.js' : '/sf/tinymce/js/tiny_mce.js';
    sfContext::getInstance()->getResponse()->addJavascript($js_path);
  }
}

Une autre méthode beaucoup plus puissante existe : la gestion intervallaire. Vous pouvez trouver une explication détaillée de cette méthode ici :
http://sqlpro.developpez.com/cours/arborescence/.

Nous allons voir dans cet article comment implémenter celle-ci dans un projet symfony 1.2 avec doctrine.

Pré-requis

• Un backend symfony 1.2, doctrine
• Comment créer un projet symfony 1.2 Doctrine :
  http://www.symfony-project.org/jobeet/1_2/Doctrine/en/03
• Comment créer une application backend :
  http://www.symfony-project.org/jobeet/1_2/Doctrine/en/12
• Tout ce post est basé sur le travail des gens de ce lien (en anglais) :
  http://redotheoffice.com/

Schéma

/config/doctrine/schema.yml

Tree:
  actAs:
    NestedSet:
      hasManyRoots: true
      rootColumnName: root_id
  columns:
    name:
      type: string(255)

Module

Créez le module :

 symfony doctrine:generate-admin backend Tree --module=tree

Formulaire

Modifiez la classe de formulaire :

/lib/form/doctrine/TreeForm.class.php

widgetSchema['parent_id'] = new sfWidgetFormDoctrineChoice(array(
      'model' => 'tree',
      'add_empty' => '~ (object is at root level)',
      'order_by' => array('root_id, lft',''),
      'method' => 'getIndentedName'
      ));
    $this->validatorSchema['parent_id'] = new sfValidatorDoctrineChoice(array(
      'required' => false,
      'model' => 'tree'
      ));
    $this->setDefault('parent_id', $this->object->getParentId());
    $this->widgetSchema->setLabel('parent_id', 'Child of');
 
  }
 
  public function updateParentIdColumn($parentId)
  {
    $this->parentId = $parentId;
    // further action is handled in the save() method
  }
 
  protected function doSave($con = null)
  {
    parent::doSave($con);
 
    $node = $this->object->getNode();
 
    if ($this->parentId != $this->object->getParentId() || !$node->isValidNode())
    {
      if (empty($this->parentId))
      {
        //save as a root
        if ($node->isValidNode())
        {
          $node->makeRoot($this->object['id']);
          $this->object->save($con);
        }
        else
        {
          $this->object->getTable()->getTree()->createRoot($this->object); //calls $this->object->save internally
        }
      }
      else
      {
        //form validation ensures an existing ID for $this->parentId
        $parent = $this->object->getTable()->find($this->parentId);
        $method = ($node->isValidNode() ? 'move' : 'insert') . 'AsFirstChildOf';
        $node->$method($parent); //calls $this->object->save internally
      }
    }
  }
}

Modèle

Modifiez la classe du modèle :

/lib/model/doctrine/Tree.class.php

getIndentedName());
  }
  public function getParentId()
  {
    if (!$this->getNode()->isValidNode() || $this->getNode()->isRoot())
    {
      return null;
    }
    $parent = $this->getNode()->getParent();
    return $parent['id'];
  }
  public function getIndentedName()
  {
    return str_repeat('- ',$this['level']).$this['name'];
  }
}

Actions

Modifier la classe action du module :

/apps/backend/modules/tree/actions

addOrderBy('root_id, lft');
  }
 
  public function executeBatch(sfWebRequest $request)
  {
    if ("batchOrder" == $request->getParameter('batch_action'))
    {
      return $this->executeBatchOrder($request);
    }
 
    parent::executeBatch($request);
  }
 
  public function executeBatchOrder(sfWebRequest $request)
  {
    $newparent = $request->getParameter('newparent');
 
    //manually validate newparent parameter
 
    //make list of all ids
    $ids = array();
    foreach ($newparent as $key => $val)
    {
      $ids[$key] = true;
      if (!empty($val))
        $ids[$val] = true;
    }
    $ids = array_keys($ids);
 
    //validate if all id's exist
    $validator = new sfValidatorDoctrineChoiceMany(array('model' => 'Tree'));
    try
    {
      // validate ids
      $ids = $validator->clean($ids);
 
      // the id's validate, now update the tree
      $count = 0;
      $flash = "";
 
      foreach ($newparent as $id => $parentId)
      {
        if (!empty($parentId))
        {
          $node = Doctrine::getTable('Tree')->find($id);
          $parent = Doctrine::getTable('Tree')->find($parentId);
 
          if (!$parent->getNode()->isDescendantOfOrEqualTo($node))
          {
            $node->getNode()->moveAsFirstChildOf($parent);
            $node->save();
 
            $count++;
 
            $flash .= "
Moved '".$node['name']."' under '".$parent['name']."'.";
          }
        }
      }
 
      if ($count > 0)
      {
        $this->getUser()->setFlash('notice', sprintf("Tree order updated, moved %s item%s:".$flash, $count, ($count > 1 ? 's' : '')));
      }
      else
      {
        $this->getUser()->setFlash('error', "You must at least move one item to update the tree order");
      }
    }
    catch (sfValidatorError $e)
    {
      $this->getUser()->setFlash('error', 'Cannot update the tree order, maybe some item are deleted, try again');
    }
 
    $this->redirect('@tree');
  }
 
  public function executeDelete(sfWebRequest $request)
  {
    $request->checkCSRFProtection();
 
    $this->dispatcher->notify(new sfEvent($this, 'admin.delete_object', array('object' => $this->getRoute()->getObject())));
 
    $object = $this->getRoute()->getObject();
    if ($object->getNode()->isValidNode())
    {
      $object->getNode()->delete();
    }
    else
    {
      $object->delete();
    }
 
    $this->getUser()->setFlash('notice', 'The item was deleted successfully.');
 
    $this->redirect('@tree');
  }
 
  public function executeListNew(sfWebRequest $request)
  {
    $this->executeNew($request);
    $this->form->setDefault('parent_id', $request->getParameter('id'));
    $this->setTemplate('edit');
  }
 
  protected function processForm(sfWebRequest $request, sfForm $form)
  {
    $form->bind($request->getParameter($form->getName()), $request->getFiles($form->getName()));
    if ($form->isValid())
    {
      $this->getUser()->setFlash('notice', $form->getObject()->isNew() ? 'The item was created successfully.' : 'The item was updated successfully.');
 
      $tree = $form->save();
 
      $this->dispatcher->notify(new sfEvent($this, 'admin.save_object', array('object' => $tree)));
 
      if ($request->hasParameter('_save_and_add'))
      {
        $this->getUser()->setFlash('notice', $this->getUser()->getFlash('notice').' You can add another one below.');
 
        //$this->redirect('@tree_new');
      }
      else
      {
        //$this->redirect('@tree_edit?id='.$tree['id']);
      }
    }
    else
    {
      $this->getUser()->setFlash('error', 'The item has not been saved due to some errors.');
    }
  }
}

Generator

Modifiez le fichier :

/apps/backend/modules/tree/config/generator.yml

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           Tree
    theme:                 admin
    non_verbose_templates: true
    with_show:             false
    singular:              ~
    plural:                ~
    route_prefix:          tree_tree
    with_doctrine_route:     1
 
    config:
      actions: ~
      fields:  ~
      list:
        title:   Gestions des catégories
        max_per_page: 999999
        batch_actions:
          order:
            label: Update tree order
          _delete: ~
        object_actions:
          new:
            label: Add Child
          _edit:    ~
          _delete:  ~
        actions:
          _new:
            label: Add Root
      filter:  ~
      form:    ~
      edit:
        title: Editing Categorie "%%name%%"
      new:     ~

Templates

Créez les fichiers suivant :
• _list.php
  

  /apps/backend/modules/tree/templates_list.php

  ^?View Code PHP

  <div class="sf_admin_list"> getNbResults()): ?> <table id="main_list" border="0" cellspacing="0"> <thead> <tr> <th id="sf_admin_list_batch_actions"> <input id="sf_admin_list_batch_checkbox" onclick="checkAll();" type="checkbox" /></th> $sort)) ?> <th id="sf_admin_list_th_actions"></th> </tr> </thead> <tfoot> <tr> <th colspan="8"> haveToPaginate()): ?> $pager)) ?>   $pager->getNbResults()), $pager->getNbResults(), 'sf_admin') ?> haveToPaginate()): ?> $pager->getPage(), '%%nb_pages%%' => $pager->getLastPage()), 'sf_admin') ?></th> </tr> </tfoot> <tbody> getResults() as $i => $tree): $odd = fmod(++$i, 2) ? 'odd' : 'even' ?> <tr id="node-<?php echo $tree['id'] ?>" class="sf_admin_row <?php echo $odd ?><?php // insert hierarchical info $node = $tree->getNode(); if ($node->isValidNode() && $node->hasParent()) { echo">getParent()->getId(); } ?>"> $tree, 'helper' => $helper)) ?> $tree)) ?> $tree, 'helper' => $helper)) ?></tr> </tbody></table> </div> <script type="text/javascript"><!--mce:0--></script>

• _list_footer.php
  

  /apps/backend/modules/tree/templates_list_footer.php

  ^?View Code PHP

  <em>After changing the order of the tree, the new order should be saved. This is currently implemented as a batch action, so please choose <strong>Update tree order</strong> from the 'Choose an action' dropdown and click on 'Go' to save the new order.</em>

• _list_td_batch_actions.php
  

  /apps/backend/modules/tree/templates_list_td_batch_actions.php

  ^?View Code PHP

  <input class="sf_admin_batch_checkbox" name="ids[]" type="checkbox" value="<?php echo $tree->getPrimaryKey() ?>" /> <input id="select_node-<?php echo $tree->getPrimaryKey() ?>" name="newparent[<?php echo $tree->getPrimaryKey() ?>]" type="hidden" />

• _list_td_tabular.php
  

  /apps/backend/modules/tree/templates/_list_td_tabular.php

  ^?View Code PHP

  <span class="<?php echo $tree->getNode()->isLeaf() ? 'file' : 'folder' ?>">   </span>

CSS/JS

• CSSCréez ce fichier :
  

  /web/css/jQuery.treeTable.css

  ^?View Code CSS

  /* jQuery TreeTable Core 2.0 stylesheet * * This file contains styles that are used to display the tree table. Each tree * table is assigned the +treeTable+ class. * ========================================================================= */   /* jquery.treeTable.collapsible * ------------------------------------------------------------------------- */ .treeTable tr td .expander { background-position: left center; background-repeat: no-repeat; cursor: pointer; padding: 0; zoom: 1; /* IE7 Hack */ }   .treeTable tr.collapsed td .expander { background-image: url(../images/toggle-expand-dark.png); }   .treeTable tr.expanded td .expander { background-image: url(../images/toggle-collapse-dark.png); }   /* jquery.treeTable.sortable * ------------------------------------------------------------------------- */ .treeTable tr.selected, .treeTable tr.accept { background-color: #ccccff !important; color: #fff !important; }   .treeTable tr.collapsed.selected td .expander, .treeTable tr.collapsed.accept td .expander { background-image: url(../images/toggle-expand-light.png); }   .treeTable tr.expanded.selected td .expander, .treeTable tr.expanded.accept td .expander { background-image: url(../images/toggle-collapse-light.png); }   .treeTable .ui-draggable-dragging { color: #000; z-index: 1; }

  Créez ce fichier :

  /web/css/main.css

  ^?View Code CSS

  table span { background-position: center left; background-repeat: no-repeat; padding: .2em 0 .2em 1.5em; }   table span.file { background-image: url(../images/page_white_text.png); }   table span.folder { background-image: url(../images/folder.png); }

• JavascriptCréez ce fichier :
  

  /web/js/jQuery.treeTable.js

  ^?View Code JAVASCRIPT

  /* jQuery treeTable Plugin 2.2 - http://ludo.cubicphuse.nl/jquery-plugins/treeTable/ */ (function($) { // Helps to make options available to all functions // TODO: This gives problems when there are both expandable and non-expandable // trees on a page. The options shouldn't be global to all these instances! var options;   $.fn.treeTable = function(opts) { options = $.extend({}, $.fn.treeTable.defaults, opts);   return this.each(function() { $(this).addClass("treeTable").find("tbody tr").each(function() { // Initialize root nodes only whenever possible if(!options.expandable || $(this)[0].className.search("child-of-") == -1) { initialize($(this)); } }); }); };   $.fn.treeTable.defaults = { childPrefix: "child-of-", expandable: true, indent: 19, initialState: "collapsed", treeColumn: 0 };   // Recursively hide all node's children in a tree $.fn.collapse = function() { $(this).addClass("collapsed");   childrenOf($(this)).each(function() { initialize($(this));   if(!$(this).hasClass("collapsed")) { $(this).collapse(); }   $(this).hide(); });   return this; };   // Recursively show all node's children in a tree $.fn.expand = function() { $(this).removeClass("collapsed").addClass("expanded");   childrenOf($(this)).each(function() { initialize($(this));   if($(this).is(".expanded.parent")) { $(this).expand(); }   $(this).show(); });   return this; };   // Add an entire branch to +destination+ $.fn.appendBranchTo = function(destination) { var node = $(this); var parent = parentOf(node);   var ancestorNames = $.map(ancestorsOf($(destination)), function(a) { return a.id; });   // Conditions: // 1: +node+ should not be inserted in a location in a branch if this would // result in +node+ being an ancestor of itself. // 2: +node+ should not have a parent OR the destination should not be the // same as +node+'s current parent (this last condition prevents +node+ // from being moved to the same location where it already is). // 3: +node+ should not be inserted as a child of +node+ itself. if($.inArray(node[0].id, ancestorNames) == -1 && (!parent || (destination.id != parent[0].id)) && destination.id != node[0].id) { indent(node, ancestorsOf(node).length * options.indent * -1); // Remove indentation   if(parent) { node.removeClass(options.childPrefix + parent[0].id); }   node.addClass(options.childPrefix + destination.id); move(node, destination); // Recursively move nodes to new location indent(node, ancestorsOf(node).length * options.indent); }   return this; };   // Add reverse() function from JS Arrays $.fn.reverse = function() { return this.pushStack(this.get().reverse(), arguments); };   // Toggle an entire branch $.fn.toggleBranch = function() { if($(this).hasClass("collapsed")) { $(this).expand(); } else { $(this).removeClass("expanded").collapse(); }   return this; };   // === Private functions   function ancestorsOf(node) { var ancestors = []; while(node = parentOf(node)) { ancestors[ancestors.length] = node[0]; } return ancestors; };   function childrenOf(node) { return $("table.treeTable tbody tr." + options.childPrefix + node[0].id); };   function indent(node, value) { var cell = $(node.children("td")[options.treeColumn]); var padding = parseInt(cell.css("padding-left"), 10) + value;   cell.css("padding-left", + padding + "px");   childrenOf(node).each(function() { indent($(this), value); }); };   function initialize(node) { if(!node.hasClass("initialized")) { node.addClass("initialized");   var childNodes = childrenOf(node);   if(!node.hasClass("parent") && childNodes.length > 0) { node.addClass("parent"); }   if(node.hasClass("parent")) { var cell = $(node.children("td")[options.treeColumn]); var padding = parseInt(cell.css("padding-left"), 10) + options.indent;   childNodes.each(function() { $($(this).children("td")[options.treeColumn]).css("padding-left", padding + "px"); });   if(options.expandable) { cell.prepend(''); $(cell[0].firstChild).click(function() { node.toggleBranch(); });   // Check for a class set explicitly by the user, otherwise set the default class if(!(node.hasClass("expanded") || node.hasClass("collapsed"))) { node.addClass(options.initialState); }   if(node.hasClass("collapsed")) { node.collapse(); } else if (node.hasClass("expanded")) { node.expand(); } } } } };   function move(node, destination) { node.insertAfter(destination); childrenOf(node).reverse().each(function() { move($(this), node[0]); }); };   function parentOf(node) { var classNames = node[0].className.split(' ');   for(key in classNames) { if(classNames[key].match("child-of-")) { return $("#" + classNames[key].substring(9)); } } }; })(jQuery);

view.yml

Modifiez ce fichier :

/apps/backend/config/view.yml

default:
  http_metas:
    content-type: text/html
 
  metas:
    #title:        symfony project
    #description:  symfony project
    #keywords:     symfony, project
    #language:     en
    #robots:       index, follow
 
  stylesheets:    [main.css, jQuery.treeTable.css]
 
  javascripts:
    - http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js
    - http://ajax.googleapis.com/ajax/libs/jqueryui/1.5.3/jquery-ui.min.js
    - jquery.treeTable.js
 
  has_layout:     on
  layout:         layout

Routing

Il faut rajouter la règle de routage « tree » !!

/apps/backend/config/routing.yml

tree_tree:
  class: sfDoctrineRouteCollection
  options:
    model:               Tree
    module:              tree
    prefix_path:         tree
    column:              id
    with_wildcard_routes: true
tree:
  class: sfDoctrineRouteCollection
  options:
    model:               Tree
    module:              tree
    prefix_path:         tree
    column:              id
    with_wildcard_routes: true
# default rules
homepage:
  url:   /
  param: { module: default, action: index }
 
default_index:
  url:   /:module
  param: { action: index }
 
default:
  url:   /:module/:action/*

Clear Cache

On vide le cache :

symfony cc

Fixtures

Ajouter ce fichier :

/data/fixtures/data.yml

Tree:
  Tree_1:
    name: Couleurs
    root_id: '1'
    lft: '1'
    rgt: '8'
    level: '0'
  Tree_2:
    name: Bleu
    root_id: '1'
    lft: '6'
    rgt: '7'
    level: '1'
  Tree_3:
    name: Rouge
    root_id: '1'
    lft: '2'
    rgt: '3'
    level: '1'
  Tree_4:
    name: Vert
    root_id: '1'
    lft: '4'
    rgt: '5'
    level: '1'
  Tree_5:
    name: Langages
    root_id: '5'
    lft: '1'
    rgt: '14'
    level: '0'
  Tree_6:
    name: Serveur
    root_id: '5'
    lft: '8'
    rgt: '13'
    level: '1'
  Tree_7:
    name: Client
    root_id: '5'
    lft: '2'
    rgt: '7'
    level: '1'
  Tree_8:
    name: Javascript
    root_id: '5'
    lft: '5'
    rgt: '6'
    level: '2'
  Tree_9:
    name: ActionScript
    root_id: '5'
    lft: '3'
    rgt: '4'
    level: '2'
  Tree_10:
    name: PHP
    root_id: '5'
    lft: '11'
    rgt: '12'
    level: '2'
  Tree_11:
    name: ASP
    root_id: '5'
    lft: '9'
    rgt: '10'
    level: '2'

build-all-reload

symfony doctrine:build-all-reload

Les images :

A copier dans web/images

	page_white_text.png
	folder.png
	toggle_collapse_dark.png
	toggle_collapse_light.png
	toggle_expand_dark.png
	toggle_expand_light.png

Aperçu

Vous devriez avoir ça !

Sources :

• http://sqlpro.developpez.com/cours/arborescence/
• http://www.symfony-project.org/jobeet/
• http://redotheoffice.com/