Wait and see mais en attendant voici la sélection de la semaine.

• Propel 1.4 stable
  C’est un peu l’annonce de la semaine. Propel 1.4 stable est sortie! Pas mal de nouveautés dont certaines reprises des bonnes idées de Doctrine, mais également quelques exclus. Peut-être un futur billet plus complet à ce sujet ;)
• Un joli thème wordpress
  Une fois n’est pas coutume, croisé au détour d’un clic, assez sobre mais bourré de petits détails.
• Un autre joli thème wordpress
  Comme quoi ya des semaines comme ça. Celui-ci est plus poussé graphiquement mais a un vrai potentiel je pense
• Event jquery sur la sélection de texte
  Fonctionnalité qui pourrait ouvrir la porte à quelques nouvelles possibilités sympa
• Un nouveau script de validation de formulaire
  Oui encore un. Ca faisait longtemps. Mais celui-ci est vraiment bien fini et permet de définir ses validations avec très peu de ligne js, tout étant calibré depuis le code html
• Memcache et le PHP
  Une petite explication sur Memcache et ses bienfaits pour le PHP
• Drag and share avec jQuery
  Une façon originale de penser le drag and drop et le partage sur les medias sociaux.
• Un compilateur javascript par Google
  C’est le lien qui a fait le tour du web, cette semaine. Le voilà décrit par dew, même s’il s’avère très compliqué d’être utilisé avec jquery, ca reste un outil assez novateur.
• Un nouvel ORM PHP
  Basé sur l’ORM de Ruby, voici un ORM dont on pourrait bien entendre parler prochainement.

Et forcément, chez les développeurs Symfony, ca frétille d’impatience car chaque jour nous rapproche de la sortie de la version 1.3 de notre framework PHP préféré, dernière release majeure avant le passage en 2.0 (oué pour le coup, ils sont pas encore à la mode).

Je me suis dis que ca valait le coup de faire un petit tour d’horizon des nouveautés attendues (au moins par moi) que se soit Symfony, Doctrine et même Propel:

Propel

On commence avec le feuilleton de l’été. Propel, mourra, mourra pas?

L’info a très vite circulé, et Propel a été enterré très vite après l’annonce de son créateur Hans Lellelid d’arrêter là les frais.

Mais dans son message, il y avait bien un appel au passage de relai, appel auquel François Zaninotto (himself, ex de la core team Symfony) et Sven Teitje ont répondu. Le premier prenant en charge l’évolution de la branche 1.x et le second le développement de la nouvelle branche 2.x.

D’ailleurs ils n’ont pas trainé car on parle déjà de Propel 1.4! On suivra bien sûr ça de très près.

Doctrine

Avec la mode 2.0, Mister Wage prépare lui aussi une version 2.0 de son ORM Doctrine. Peu d’infos encore si ce n’est qu’il sera plus beau, plus fort et surtout plus rapide! Grâce à PHP 5.3 en particulier.
Mais on pourra également retrouver des messages d’erreurs localisés! Et ça c’est la classe.

Mais ceci reste du futur pas proche. Et on va s’intéresser plutôt à la version 1.2, celle qui accompagnera la version 1.3 de Symfony (oui j’avoue, ils auraient pu se mettre d’accord sur les numéros de version, ça aurait été plus simple).

Et la nouveauté majeure pour moi, c’est la possibilité d’étendre les classe de Doctrine facilement et en particulier Doctrine_Query et Doctrine_Collection. On pourra alors généraliser certains comportements et ajouter de nouvelles fonctionnalités comme des tri personnalisés dans les collections ou adapter l’idée de NiKo pour les query.

On notera également, l’ajout d’un système d’extension directement via doctrine qui sont en fait des behaviors. Vous retrouverez la liste sur le site lui même. J’ai d’ailleurs de mon côté, une petite idée d’extension, mais on en reparlera le moment voulu ;)

Symfony

Gros programme pour cette dernière release (comme annoncée, la 1.4 ne sera qu’une 1.3 débarrassé des méthodes/classes dépréciées). Beaucoup de choses, mais voici un résumé de celles que j’attends vraiment:

• La vrai nouveauté, un Mailer de série! Basé sur Swift, très bonne librairie, cela fera toujours un plugin de moins à utiliser
• Le système de formulaire pluggué sur le système d’évènement avec 4 nouveaux évènements qui va permettre enfin de généraliser des comportements pour certains formulaires très facilement.
• Pouvoir ne pas générer les formulaires ou filtres d’un modèle lors de sa définition dans le schema.yml (seulement doctrine). Nan parce que, c’est vrai que des fois, on en a vraiment pas besoin.
• Petit détail enfin corrigé, les pager intègrent enfin les interfaces Countable et Iterator.
• Autre détail, à la génération automatique d’un label d’un champ de formulaire, les _id seront supprimés! Ca permettra d’avoir quelque chose de présentable plus facilement, pcq les _id nous on les voit pas, mais les clients, ca leur saute toujours aux yeux ;)
• Petite révolution dans les définitions de formulaire. Actuellement, il faut retirer du formulaire les champs qu’on ne souhaite pas voir s’afficher. Mais le coup classique du « je rajoute un champ et il apparait automatiquement alors que je voulais pas » ça agace. Dans la 1.3, ca sera donc l’inverse, il faudra spécifier les champs qu’on voudra afficher grâce à la nouvelle méthode useFields
• Niveau CLI aussi beaucoup de nouveautés, dont une assez formidable, la possibilité de rejouer seulement les tests qui auront échoué! Il suffira de rajouter l’option –only-failed.
• Pour Doctrine aussi, beaucoup de rajouts bien pratiques, comme la possibilité de regénérer/supprimer les fichiers liés à un model donné. Et même de resynchroniser tous les modèles avec le schema.yml (entendre par là qu’il supprimera ceux qui n’existe plus). Des petits gains de temps qui ne sont pas de refus, surtout dans les débuts d’un nouveau projet.
• Et bien sûr, la plus attendue pour la fin. Fabien en avait déjà parlé sur le blog, la possibilité de créer un installer pour la génération de nouveau projet qui fera automatiquement toutes les tâches de personnalisation que vous faisiez avant à la main ou en maintenant votre skeleton de projet.

En tout cas, ça fait envie, et ca va dans le bon sens selon moi. Pour tous les détails:

• Slides de Jonathan Wage sur Symfony 1.3 et Doctrine 1.2
• Page officielle des nouveautés de la v1.3

Crédit photo: http://www.flickr.com/photos/mfobrien

  cross_selling:
    _attributes: { phpName: CrossSelling }
    pid: { type: SMALLINT, size: '5', primaryKey: true, required: true, foreignTable: produits, foreignReference: pid, onDelete: CASCADE, onUpdate: CASCADE }
    csid: { type: SMALLINT, size: '5', primaryKey: true, required: true, foreignTable: produits, foreignReference: pid, onDelete: CASCADE, onUpdate: CASCADE }

Autant dans la partie model, aucun souci, on est capable de récupérer chacun des éléments par la table « Produits » (la table où pointe les 2 clés étrangères pour ceux qui se sont perdus en route), autant dans la partie form, aucune trace du widget pour matérialiser cette relation, rien, nada. Alors qu’au départ, si on définie notre relation, c’est qu’on en a un peu besoin en fait.

On va donc tâcher de combler ce vide, en rajoutant ce dont a besoin notre formulaire pour reproduire notre relation dans le fichier lib/form/ProduitsForm.class.php

class ProduitsForm extends BaseProduitsForm
{
  public function configure()
  {
    parent::configure();
    // Ajout Cross Selling
    $this->widgetSchema['cross_selling_list'] = new sfWidgetFormPropelChoiceMany(array(
    	'model' => 'Produits'
    ));
    $this->validatorSchema['cross_selling_list'] = new sfValidatorPropelChoiceMany(array('model' => 'Produits', 'required' => false));
  }

On crée ensuite la méthode qui va permettre d’enregistrer le résultat de notre choix dans notre widget de liste (en fait, il suffit d’adapter le code généré pour une relation many-to-many qui fonctionne):

public function saveCrossSellingList($con = null)
  {
    if (!$this->isValid())
    {
      throw $this->getErrorSchema();
    }
 
    if (!isset($this->widgetSchema['cross_selling_list']))
    {
      // somebody has unset this widget
      return;
    }
 
    if (is_null($con))
    {
      $con = $this->getConnection();
    }
 
    $c = new Criteria();
    $c->add(CrossSellingPeer::PID, $this->object->getPrimaryKey());
    CrossSellingPeer::doDelete($c, $con);
 
    $values = $this->getValue('cross_selling_list');
    if (is_array($values))
    {
      foreach ($values as $value)
      {
        $obj = new CrossSelling();
        $obj->setPid($this->object->getPrimaryKey());
        $obj->setCsid($value);
        $obj->save();
      }
    }
  }

Puis on surcharge le doSave pour ajouter cette fonction:

protected function doSave($con = null)
  {
    parent::doSave($con);
 
    $this->saveCrossSellingList($con);
  }

et pour finir on surcharge la méthode updateDefaultsFromObject pour charger le résultat une fois sauvegardé:

public function updateDefaultsFromObject()
  {
    parent::updateDefaultsFromObject();
 
    if (isset($this->widgetSchema['cross_selling_list']))
    {
      $values = array();
      foreach ($this->object->getCrossSellingsRelatedByPid() as $obj)
      {
        $values[] = $obj->getCsid();
      }
 
      $this->setDefault('cross_selling_list', $values);
    }
  }

Et voilà, Propel n’a qu’a bien se tenir, on peut se passer de lui! Je pense qu’avec un peu plus de temps, je me plongerai bien dans le détail pour voir où ça coince, à moins que j’ai loupé encore une fois un épisode.

Moralité, Doctrine vaincra?

J’ai donc tenté de voir du côté de Mysql, pour mettre ce dernier par défaut en utf8, mais là aussi, on a beau remplir le my.cnf de utf8 dans toutes les options, rien de concret ne se produit.

J’en été donc resté à devoir rajouter à la main, dans mon .sql généré par symfony, le fameux « DEFAUT CHARSET=UTF8″. Mais devoir le rajouter à chaque modification de mon schema, cela peut devenir pénible dans des projets de tests.

Et puis par hasard au détour d’une conversation sur mysql dans une mailing-list (mea culpa j’ai pas noté l’adresse) je suis enfin tombé sur quelque chose qui fonctionne! A la création de la table, écrire:

CREATE DATABASE mydb CHARACTER SET utf8 COLLATE utf8_general_ci

Voilà, toutes les tables créés maintenant dans cette base seront en UTF8 par défaut.

Il y a sans doute mieux, mais pour l’instant je me contente de ça. Mais peut-être que quelqu’un a une meilleur solution? Comment gérez-vous vos tables en UTF8?

• la remise en état des liens modifier/supprimer
• l’ajout d’un lien pour ajouter un enfant à une catégorie
• la sauvegarde de l’ordre de l’arbre

Ya du boulot, alors on se lance.

Le seul problème à la remise des liens modifier/supprimer c’est leur structure HTML, en ul/li qui pose souci avec le plugin NestedSortable. On va donc revoir la chose en les mettant dans un « p » avec de simples liens. Pour cela on va éditer dans notre module le fichier lib/categoriesGeneratorHelper.class.php (qui doit être vierge pour l’instant) et on va surcharger les méthodes, linkToEdit et linkToDelete:

  public function linkToEdit($object, $params)
  {
    return '<span class="sf_admin_action_edit">'.link_to(__($params['label'], array(), 'sf_admin'), $this->getUrlForAction('edit'), $object).'</span>';
  }
 
public function linkToDelete($object, $params)
  {
    if ($object->isNew())
    {
      return '';
    }
 
    return '<span class="sf_admin_action_delete">'.link_to(__($params['label'], array(), 'sf_admin'), $this->getUrlForAction('delete'), $object, array('method' => 'delete', 'confirm' => !empty($params['confirm']) ? __($params['confirm'], array(), 'sf_admin') : $params['confirm'])).'</span>';
  }

Les seules modifications concernant le changement d’un li par un span.

Maintenant on va modifier le partial _list_td_actions.php et donc le rajouter dans notre répertoire templates de notre module:

<p class="sf_admin_td_actions list_action">
  <span class="sf_admin_action_new">
    <?php echo link_to(__('Ajout Enfant'), 'categories/addChild?id='.$categories->getId(), array(), 'messages') ?>
  </span>
  <?php echo $helper->linkToEdit($categories, array(  'params' =>   array(  ),  'class_suffix' => 'edit',  'label' => 'Edit',)) ?>
  <?php echo $helper->linkToDelete($categories, array(  'params' =>   array(  ),  'confirm' => 'Are you sure?',  'class_suffix' => 'delete',  'label' => 'Delete',)) ?>
</p>

A noter qu’on a ajouté au passage l’action Ajout d’enfant.
Il nous reste plus qu’à rajouter l’appel à ce partial dans notre _tree.php:

[...]
<div class="sort-handle">
   <?php echo $node->getTitre() ?>
</div>
<?php include_partial('categories/list_td_actions', array('categories' => $node, 'helper' => $helper)) ?>
[...]

Le résultat nous donne ceci:

Alors oui c’est moche, mais ca fonctionne! Maintenant, on passe un petit coup de CSS comme d’habitude:

.list_action {
	position: absolute;
	right: 0; top:0;
	width: 350px;
}
 
.list_action span {
	padding: 0 10px 0 0;
}
 
.current-nesting {
	background-color: #FFE;
}
 
#sf_admin_container #sf_admin_content p span.sf_admin_action_new a {
	background:transparent url(/sfPropelPlugin/images/new.png) no-repeat scroll 0 0;
}
#sf_admin_container #sf_admin_content p span.sf_admin_action_edit a {
	background:transparent url(/sfPropelPlugin/images/edit.png) no-repeat scroll 0 0;
}
#sf_admin_container #sf_admin_content p span.sf_admin_action_delete a,.link_delete {
	background:transparent url(/sfPropelPlugin/images/delete.png) no-repeat scroll 0 0;
}

Et la magie opère de nouveau:

On va maintenant créer les actions liées à cette nouvelle action dans notre fichier d’actions de notre module:

public function executeAddChild(sfWebRequest $request)
  {
    $this->categories = $this->getRoute()->getObject();
 
    // On récupère le parent pour insérer la nouvelle catégorie sous ce parent et on le fait transiter via session 
    $this->getUser()->setAttribute('categories.addChild',$this->categories->getPrimaryKey(), 'admin_module');
 
    $this->form = $this->configuration->getForm();
    $this->setTemplate('new');
  }
 
  /**
   * On surcharge le processForm pour récupérer le parent de la catégorie à ajouter s'il existe
   *
   * @param sfWebRequest $request
   * @param sfForm $form
   */
  protected function processForm(sfWebRequest $request, sfForm $form)
  {
    if ($parent = $this->getUser()->getAttribute('categories.addChild', null, 'admin_module'))
    {
      $this->getUser()->getAttributeHolder()->remove('categories.addChild', null, 'admin_module');
      $root = CategoriesPeer::retrieveByPk($parent);
      $form->getObject()->insertAsLastChildOf($root);
    }
 
    parent::processForm($request,$form);
  }

Si vous cliquez maintenant sur « Ajouter un enfant’ d’une des catégories déjà présente vous obtenez alors:

Vu que les tree left et tree right sont définis par Propel, on va les supprimer du formulaire.
Dans notre CategoriesForm.class.php on rajoute:

public function configure()
  {
    unset(
      $this['tree_left'],
      $this['tree_right']
    );
  }

Maintenant, il ne manque plus qu’à pouvoir sauvegarder les modifications d’ordre effectuées via javascript. Pour cela on va rajouter une batch actions (elles soumettent un formulaire, il sera ainsi plus facile de faire passer les modifications faites à l’arbre).
Dans notre generator.yml on rajoute dans l’entrée list:

  batch_actions:
    saveOrder:
      label: Sauvegarder ordre
      action: saveOrder

Et dans notre partial _list.php, juste avant le javascript:

<div>
	<input type="hidden" id="hashValue" name="hashValue" value="" />
	<input type="hidden" name="ids" value="<?php echo (!empty($item)?$item->getPrimaryKey():'1') ?>" />
</div>

Le premier pour récupérer la sérialisation de la nestedlist en javascript, le deuxième pour passer outre le système de batch qui demande de sélectionner au moins un ids pour lancer l’action ensuite.

On obtient donc:

Il ne reste plus qu’à faire l’action correspondante dans notre fichier d’actions:

public function executeBatchSaveOrder(sfWebRequest $request)
  {
    $hash = $request->getParameter('hashValue');
    parse_str($hash, $list);
    CategoriesPeer::saveOrder($list);
    $this->getUser()->setFlash('notice', 'Ordre mis à jour');
  }

Et les fonctions de sauvegarde dans notre modèle. La fonction mère dans le CategoriesPeer.php:

public static function saveOrder($hash)
  {
    $root = self::retrieveRoot();
 
    foreach ($hash['main_list'] as $categorie)
    { 
      $u = self::retrieveByPk($categorie['id']);
 
      if (!empty($categorie['children']))
      {
        $u->saveChildren($categorie['children']);
      }
 
      $u->moveToLastChildOf($root);
      $u->save();
    }
  }

Qui gère les « racines » et son équivalent récursif dans le model Categories.php:

       public function saveChildren($children)
	{
	  foreach($children as $child)
	  {
	    $item = CategoriesPeer::retrieveByPk($child['id']);
	    if (!empty($child['children']))
	    {
	      $item->saveChildren($child['children']);
	    }
	    $item->moveToLastChildOf($this);
            $item->save();
	  }
	}

Et voilà! Vous pouvez maintenant déplacer vos catégories et sauvegarder leur position dans l’arbre.

Evidemment toute question, suggestion sont bien sûr les bienvenues. Je pense mettre les source et une démo en ligne très bientôt, voir en faire un plugin si jamais je rencontre un réel intérêt pour ce genre de gadget.

En attendant, une petit illustration en vidéo:

Ici, le principe va être justement de gérer un arbre de catégories, un cas qui peut revenir assez régulièrement. A noter que le concept reprend la version doctrine de redotheoffice avec une modification quant au plugin jquery utilisé. En effet, on essaiera ici de gérer l’ordre des catégories également par drag and drop.

En général, quand on part la tête dans le guidon, on crée une table categories, et pour créer la notion de parent, on applique une clé étrangère sur cette même table. Oui mais voilà, autant pour les opérations de suppression et d’ajout, voir même de déplacement dans l’arbre cette démarche est très performante, autant quand il s’agit d’afficher l’arbre, la galère commence.
Et pourtant, c’est bien cette deuxième qu’on fait à chaque affichage de page!

Il existe pourtant une alternative à cette clé étrangère: les Nested Set. En français, les représentations intervallaires. Le but n’étant pas d’expliquer dans le détail ce que c’est, je vous invite à faire un tour sur développez.com où on retrouve un très bon article illustré à ce sujet.

Brièvement, cette méthode consiste à rajouter des champs en base, left, right et scope permettant de retrouver ses petits. Le diagramme de developpez.com résume bien:

Ok, c’est bien, mais appliquer tout ça à symfony ca doit être lourd! Et bien nan, Propel dans sa dernière version (1.3) intègre déjà cet algorithme en tant que behavior. (Cela sous entend qu’il faut utiliser symfony 1.2)

Pour se faire, on va donc créer un project vierge en 1.2 histoire d’éviter tout parasitage qu’on mènera en 2 parties. La première pour la partie visuel, la deuxième pour la partie code admin generator.

Voici le résultat attendu à la fin de cette première partie:

On se lance donc, notre beau projet est créé, on ouvre le schema.yml que l’on modifie comme ceci:

propel:
  categories:
    _attributes: { phpName: Categories, treeMode: NestedSet }
    id: ~
    titre: { type: VARCHAR, size: '50', required: true }
    tree_left: { type: INTEGER, size: '11', required: true, nestedSetLeftKey: true }
    tree_right: { type: INTEGER, size: '11', required: true, nestedSetRightKey: true }
    tree_parent: { type: INTEGER, size: '11', required: true }

Vous noterez donc l’ajout du treeMode et la définition des nesetSetLeftKey et nestedSetRightKey, le tree_parent, n’est là que pour un certain confort à l’affichage, mais pas indispensable.

Votre schema ainsi terminé (vous pouvez y rajouter d’autres tables, même pas peur), on construit la base correspondante (en ayant au préalable configuré notre database.yml évidemment:

php symfony propel:build-all

Et là on constate dans notre dossier lib, deux nouvelles classes que vous n’avez sans doute jamais vu:

- BaseCategoriesNestedSet
- BaseCategoriesNestedSetPeer
qui viennent se placer entre entre les classes classiques et les classes « Base »

Afin de jouer rapidement, on va ajouter quelques valeurs test dans data/fixtures/fixtures.yml comme suit:

Categories:
  cat_1:
    titre: root
    tree_left: 1
    tree_right: 10
  cat_2:
    titre: Hi-Tech
    tree_left: 2
    tree_right: 7
  cat_3:
    titre: Developpement
    tree_left: 3
    tree_right: 4
  cat_4:
    titre: Internet
    tree_left: 5
    tree_right: 6
  cat_5:
    titre: Culture
    tree_left: 8
    tree_right: 9

que l’on va charger dès à présent:

php symfony propel:data-load

A noter que la notion de root est ici très importante. En effet, j’ai choisi délibérément de travailler avec un seul scope (une seule racine) pour la simple et bonne raison que les manipulations entre scope sont très limitées et l’intérêt et de pouvoir y faire tout et n’importe quoi. Il nous faut donc un élément parent de tous, que l’on ne modifiera jamais, que l’on n’affichera jamais.

Maintenant, les choses sérieuses commencent. On va commencer par générer un module admin generator:

php symfony generate:app main
php symfony propel:generate-admin main Categories

Et vous devriez arriver via http://monlocal/categories sur quelque chose d’assez classique:

L’idée est maintenant d’inclure un plugin jquery qui va matérialiser notre arbre, propel ne s’occupant évidemment que de la logique métier.
J’ai choisi le très bon NestedSortable qui répond très bien en terme de performance et très flexible à configurer. Vous pouvez donc télécharger la dernière version. Seul bémol, il nécessite Interface, un équivalent à jquery UI, que l’on va donc télécharger également.
Pour jQuery, on laissera google faire.

On a donc nos js comme ceci:

et on les intègre à notre projet via notre view.yml (la notation en ligne étant plus claire à mon goût):

  javascripts: 
    - http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js
    - interface.js
    - inestedsortable-1.0.1.pack.js

On va devoir maintenant modifier un peu quelques partials car le plugin jquery nécessite une imbrication de tag html, ici on utilisera ce qui semble être le plus apte sémantiquement parlant, des couples ul/li.

L’idée est donc d’afficher tout l’arbre quelque soit le nombre d’élément et de n’afficher que l’info qui nous interesse, en l’occurrence le titre. Première chose, voici la modification sur le generator.yml:

      list:
        peer_method: retrieveTree
        max_per_page: 99999
        display: [titre]

Vous n’avez maintenant plus qu’un seul élément affiché dans votre tableau, l’élément root et c’est normal.

La suite se passe dans le partial _list.php. Rapide brief pour ceux qui n’ont jamais modifier un partial de l’admin generator. On récupère la version qui est dans le dossier cache/[APP]/[ENV]/modules/auto[MODULE]/templates et on la copie dans notre dossier templates de notre module généré.

Une fois cette opération effectuée, rien n’a du changer, mais maintenant on a la possibilité de modifier le partial, et voici un extrait de ce qu’il faut modifier dans la balise tbody:

     <tbody>
        <tr>
            <td class="container_main_list" colspan="3">
              <?php foreach ($pager->getResults() as $i => $item): ?>
                <?php include_partial('categories/tree',array('tree' => $item, 'i' => $i, 'helper' => $helper)) ?>
              <?php endforeach; ?>
            </td>
        </tr>
      </tbody>

Puis dans la partie script tout en base (vous pouvez retirer l’ancienne fonction checkAll, on ne pourra plus s’en servir:

<script type="text/javascript">
/* <![CDATA[ */
$(document).ready(function()  {
  $('#main_list').NestedSortable(
    {
      accept: 'item_list',
      opacity: 0.6,
      autoScroll: true,
      revert: true,
      nestingPxSpace: '15',
      handle: '.sort-handle',
      currentNestingClass: 'current-nesting',
      noNestingClass: 'sf_admin_td_actions',
      onChange: function(serialized) {
	$('#hashValue').val(serialized[0].hash);
      } 
    }
  );
});
/* ]]> */
</script>

Bon si vous avez suivi, vous vous doutez que si vous actualisez, symfony vous dira gentiment qu’il manque le partial _tree.php. Et bien créons le! C’est la base même du tuto, car c’est un partial récursif, qui va donc s’auto inclure:

<ul <?php echo (!empty($i)?'id="main_list" ':'')?>class="page-list">
  <?php foreach($tree->getChildren() as $node): ?>
    <li class="item_list clear-element" id="ele-<?php echo $node->getPrimaryKey() ?>">
      <div class="sort-handle">
        <?php echo $node->getTitre() ?>
			</div>
      <?php if ($node->hasChildren()): ?>
            <?php include_partial('categories/tree',array('tree' => $node, 'helper' => $helper)) ?>
      <?php endif; ?>
    </li>
  <?php endforeach; ?>
</ul>

Et là, un petit coup de F5 et la magie comment à opérer. Vous pouvez maintenant déplacer les éléments de branche en branche tel un hibou… bref, ca fonctionne!

Un petit coup de css s’impose pour que ca se rapproche le plus possible des autres modules classiques:

#sf_admin_container table tr:hover {
	background-color: #FFF;
}
 
ul#menu li{
	list-style: none;
	display: inline;
	padding: 0 10px 0 0 ;
}
 
#admin_content ul {
	margin: 0;
	list-style-position: inside;
}
 
#admin_content ul#list-container {
	margin-left: 1em;
	background-color: #FFF ;
	padding: 10px ;
}
 
#admin_content ul li {
	list-style-position: inside;
}
 
li img {
	vertical-align: text-bottom ;
}
 
#list-container li span {
	cursor: pointer;
}
 
#sortHelper {
	background: #FFE;
}
 
#dragHelper {
	background-color: #EEE;
}
 
div.wrap {
	border:1px solid #BBBBBB;
	padding: 1em 1em 1em 1em;
}
#main_list,#contenu_list {
	width: 700px;
}
 
#main_list li {
	list-style-type: none;
	list-style-position: none;
}
 
.page-list {
	list-style: none;
	margin: 0;
	padding: 0;
	display: block;
}
 
.clear-element {
	clear: both;
	position: relative;
}
 
.sort-handle {
	cursor:move;
	margin: 0.25em 0 0 0;
	padding: 2px 0 2px 18px;
	background: #f3F3F3 left center url(../images/toggleexpanddark.png) no-repeat;
}
 
div.item-title {
	background-color: #DDD;
	margin: 0.25em 0 0 0;
	padding: 2px 0 2px 18px;
}
 
.list-action {
	/*background-color: #f3F3F3;*/
	position: absolute;
	right: 0; top:0;
	width: 350px;
}

Et l’image qui va bien (récupéré de redotheoffice):

Et voilà, la première étape s’achève ici, on peut s’amuser à déplacer ces éléments. La suite très prochainement, pour remettre les actions et ajouter une action pour sauvegarder l’arbre.

A noter que je ne détaille pas forcément toutes les étapes de création d’un projet symfony, Jobeet le fais si bien.

Évidemment, toutes remarques, questions, propositions, meilleurs solutions sont les bienvenues! Je suis aussi là pour apprendre : )