L’idée dans le tuto d’aujourd’hui est de faire un petit point sur la partie « security » très bien documentée sur le site officiel mais qui change assez des habitudes de symfony 1 et donc semble un peu déroutante au début.

Ce billet est issu de ma propre et récente expérience sur le sujet et sur la branche master de fabien. Les choses peuvent changer ou être inexactes. Dans ce dernier cas, n’hésitez pas à me reprendre via les commentaires ;)

Contexte

Pour l’illustration, je vais simplement partir de la sandbox officielle d’origine configurée sur l’url suivante en local chez moi :

http://sandbox.local

et où je vais vous montrer comment y intégrer votre admin avec un formulaire d’identification sur l’url suivante :

http://sandbox.local/admin/

L’utilisateur sera géré directement via la config, pas de bdd, on veut quelque chose de très simple et rapide à mettre en place.

Première chose à comprendre dans une application Symfony2, il n’y a plus qu’une application… Oui hein, ça parait fou dis comme ça :D Toute la séparation se situe au niveau des bundles, chacun d’eux pouvant embarquer des modèles, controllers, vues différentes, tout en pouvant communiquer avec les autres bundles. Fini les galères pour faire des liens entre un backend et un frontend !

Pour notre admin, nous allons donc générer un nouveau bundle dans notre application via la commande :

php app/console init:bundle Application/AdminBundle

On se retrouve donc avec un controller basique dans ce bundle qui sera la base de notre admin. Première chose à faire, l’activer dans le fichier app/AppKernel.php via la méthode registerBundles.

Mise en place url admin

On va maintenant tenter d’y accéder via l’url /admin/

Pour ça, c’est très simple ! On va modifier notre fichier routing.yml (ou xml ou php hein, mais moi j’aime bien le yml ! ) comme ceci :

#path:app/config/routing.yml
 
homepage:
    pattern:  /
    defaults: { _controller: FrameworkBundle:Default:index }
 
hello:
    resource: HelloBundle/Resources/config/routing.yml
 
admin:
   resource: AdminBundle/Resources/config/routing.yml
   prefix: /admin

et du coup créer le fichier de routing de notre nouveau AdminBundle. Pour ça, on va faire quelque chose de très simple aussi:

#src/Application/AdminBundle/Resources/config/routing.yml
admin_homepage:
  pattern:  /
  defaults: { _controller: AdminBundle:Default:index }

Et par magie, maintenant, si vous accédez à l’url :

http://sandbox.local/admin/

Vous obtenez le mot « Hello » qui n’est d’autre que la vue par défaut qui a été générée par la commande init:bundle
Pour pas se perdre, on va modifier la vue, pour y indiquer le mot admin, ca sera plus clair.

Sécuriser l’url d’admin

2e étape, comment sécuriser tout ça pour ne pas laisser tout le monde accéder à votre admin. Pour ça il y a en fait plusieurs solutions.

• Sécuriser toutes les urls de votre application, en autorisant les connexions anonymes partout, sauf dans votre admin
• Sécuriser toutes les urls de votre admin seulement

La 1ere a l’avantage de faire écrire très peu de ligne de config, mais honnêtement, je ne sais pas s’il y en a une de meilleure que l’autre, donc je présente la première dans ce tuto, mais je vous met le code de la deuxième à la fin. Elles font sensiblement la même chose.

On va donc se lancer dans la config du component security. Pour ça, on se retrouve dans notre config.yml pour y ajouter un provider, qui sera en fait le compte utilisateur de notre admin.

#app/config/config.yml
security.config:
  providers:
    admin:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }

Nous voici avec un compte « monadmin » identifié grâce au mot de passe « monpass » qui sera crédité de l’autorisation « ROLE_ADMIN » (pour pourriez mettre TOTO à la place de ADMIN, ca changerait rien, par contrel mot ROLE est apparemment obligatoire)

Pour l’instant, ca ne change rien. Définissons maintenant une règle firewall ! Le mot utilisé pour définir ce nouveau service fait sourire j’avoue, en fait il s’agit de définir des règles de sécurité pour des motifs d’urls.

On reste dans notre config.yml qu’on enrichit comme ceci:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN  }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true

Et là, vous obtenez normalement une demande d’authentification HTTP sur tout votre site. Ok! Maintenant, on va autoriser des connexions anonymes, c’est à dire qu’on ne va pas forcer les gens à se connecter:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      http_basic: true
      anonymous: true

Maintenant, voyons voir pour mettre en place un formulaire plus conventionnel (et il me semble plus secure si bien fait, mais à confirmer).

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true

Ici on a changé le mode d’authentification pour celui d’un formulaire classique, grâce à l’option form-login

Maintenant, on va verrouiller l’accès à notre admin. Pour ce faire, on va demander une autorisation pour notre url /admin:

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, si vous essayez d’accéder à l’url :

http://sandbox.local/admin/

Vous êtes redirigés vers l’url:

http://sandbox.local/login/

qui se termine en 404! Jusqu’ici c’est normal.

Symfony2 par défaut, utilise 3 urls pour la gestion de l’authentification :

• login
• login_check
• logout

Nous allons donc les rajouter dans notre routing.yml tout simplement. Attention de bien les mettre au début, histoire d’éviter tout conflit avec une autre de vos règles.

_security_login:
  pattern: /login
  defaults: { _controller: AdminBundle:Default:login }
 
_security_check:
  pattern: /login_check
 
_security_logout:
    pattern: /logout

Le login a besoin de nous pour constituer le formulaire d’identification, les 2 autres doivent seulement exister ! Les patterns des urls peuvent varier, mais il faut alors donner les nouveaux paths dans le config.yml, nous verrons ça plus tard.

Maintenant, si nous accédons à notre admin nous avons bien sûr l’exception suivante:

Method "Application\AdminBundle\Controller\DefaultController::loginAction" does not exist.

On la crée donc:

<?php
// src/Application/AdminBundle/Controller/DefaultController.php
 
namespace Application\AdminBundle\Controller;
 
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\Security\SecurityContext; // à rajouter
 
class DefaultController extends Controller
{
    public function indexAction()
    {
        return $this->render('AdminBundle:Default:index.php');
    }
 
    public function loginAction()
    {
       // get the error if any (works with forward and redirect -- see below)
      if ($this->get('request')->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
          $error = $this->get('request')->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
      } else {
          $error = $this->get('request')->getSession()->get(SecurityContext::AUTHENTICATION_ERROR);
      }
 
      return $this->render('AdminBundle:Default:login.twig', array(
          // last username entered by the user
          'last_username' => $this->get('request')->getSession()->get(SecurityContext::LAST_USERNAME),
          'error' => $error,
      ));
    }
}

Donc là, j’ai simplement récupéré le code fourni dans la doc officielle, pas de mystère non plus. Et voici la vue correspondante :

<form action="{% path "_security_check" %}" method="post">
 
  {% if error %}
	<div class="notification error png_bg">
		<div>
			{{ error }}
		</div>
	</div>
  {% endif %}
 
  <p>
      <label>Username</label>
	<input class="text-input" type="text" name="_username" value="{{ last_username }}" />
   </p>
   <p>
      <label>Password</label>
      <input class="text-input" type="password" name="_password" />
   </p>
   <p id="remember-password">
      <input type="checkbox" />Remember me
   </p>
 
   <p>
	<input class="button" type="submit" name="login" value="Sign In" />
   </p>
</form>

Là aussi, très basique mais ça vous donne l’occasion d’essayer twig ;) Ce qui compte pour le coup, c’est surtout les attributs name des input (_username et _password), et de rediriger vers /login_check

A noter que l’utilisation du tag path dans la dernière version de twig n’est plus d’actualité. C’est désormais une fonction, donc à utiliser comme ceci {{ path(‘_security_check’) }}

Alors oui, il faudrait un layout et tout, mais bon, on va aller droit à l’essentiel.

On retrouve bien notre formulaire de login maintenant, si on essaye d’accéder à notre admin ! Encore mieux, si on essaye de s’authentifier, avec le couple login/password défini au début, on obtient notre page « admin! » Et il suffit d’ajouter une dernière ligne à notre config, pour ajouter le listener manquant sur le /logout :

#app/config/config.yml
security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_ADMIN }
 
  firewalls:
    admin:
      pattern: .*
      form_login: true
      anonymous: true
      logout: true
 
  access_control:
      - { path: /admin/.*, role: ROLE_ADMIN }

Et maintenant, vous pouvez vous déloguer sur l’url :

http://sandbox.local/logout

Histoire d’illustrer un peu plus, voici une autre config qui fonctionne aussi et qui permet de ne sécuriser que l’admin:

security.config:
  providers:
    main:
      users:
        monadmin: { password: monpass, roles: ROLE_TOTO }
 
  firewalls:
    admin: { pattern: /admin/.*, form_login: true }
    login: { pattern: /login, anonymous: true, form_login: true }
    login_check: { pattern: /login_check, anonymous: true, form_login: true }
    logout: { pattern: /logout, form_login: true, logout: true }
 
  access_control:
       - { path: /admin/.*, role: ROLE_TOTO }

Il y a bien sûr, beaucoup de tuning possible, pour encoder le password par exemple, mais maintenant qu’on a la base, je vous laisse lire vraiment la doc entière cette fois-ci ;)

Et bien ça tombe bien car Vince et moi même avons la chance d’y être également !

Se rendre au Symfony Live

Bon ce fut tout un marathon pour moi, levé 5h30 (et ceux qui me connaissent savent que c’est déjà un exploit :D), tram puis métro pour attraper mon TGV Marseille-Paris de 6h30.
Arrivé à la gare de Lyon à 9h30, on repart pour une session métro, pour enchainer sur à nouveau un peu de tram avant d’arriver devant la Cité Internationale, endroit de Paris que je ne connaissais pas !

C’est déjà une belle surprise, l’endroit est fort sympathique, très joli, mais très graaand. Et j’ai pas trouvé les grandes affiches que j’attendais « Symfony C’est par là ». Bon finalement je débarque sur les coups de 10h30, badge, tour de cou et petit sac de goodies pour m’accueillir et me voilà dans l’arène.

Heureusement, il restait quelques croissants, parce que forcément j’avais fait l’impasse sur le petit déjeuner et je vais pas vous rappeler les tarifs prohibitifs de la SNCF. Juste de quoi me réveiller un peu et commencer à mettre en route mon cerveau qui jusque là ne voulait qu’une chose, se coucher.

la matinée

Internationalisation

On commence la journée par la présentation de Thomas Rabaix concernant l’internationalisation et Symfony.

Quelques rappels sur ce qu’est l’internationalisation, des astuces sympa comme comment traduire vos routes, mais aussi et surtout la présentation du plugin qu’il a réalisé pour Menu Gourmet : mgI18nPlugin. Il permet de traduire à la volée toutes les chaînes statiques de votre page en utilisant une petit interface qui se place au dessus du site, à essayer d’urgence !
Bref très bonne première présentation.

Vous pourrez trouver les slides de sa présentation sur son site.

Admin generator en détail

John Cleveley nous a fait une petite piqure de rappel des nouveautés de l’admin generator depuis la version 1.0. Il a aussi été l’auteur du slide le plus classe de la journée concernant l’administration « backend » : un éléphant se soulageant le derrière dans un seau … ;-)

Il a rappelé que l’admin generator c’était bien, mais pas forcément pour tout. Qu’il fallait réfléchir au besoin avant de l’utiliser, plutôt que de partir avec tête baissée et se rendre compte plus tard qu’on passe plus de temps à galérer avec par rapport à ce qu’on veut faire qu’autre chose (sa remarque est d’ailleurs valable pour tout développement : c’est généralement une bonne idée de réfléchir avant de se lancer ! ).

Si vous voulez créer votre propre thème, vous pouvez vous inspirer de sfAdminDashPlugin et de sfAdminThemejRollerPlugin.

Il a aussi re-précisé que sfContext::getInstance c’était le mal (même si lui l’utilisait dans ses slides) et a fini par parler de la facilité de modifier/étendre les filtres grâce au form framework. En ce qui concerne les form, il est préférable d’en créer un nouveau pour chaque form du backend, histoire de pas confondre les forms front et back.

Il a conseillé d’utiliser le moins possible le generator pour les label, help etc des forms, mais de tout laisser dans le form : beaucoup plus facile à maintenir.

Windows plaide coupable

Surement parce qu’ils sont sponsor, on a retrouvé une équipe de Microsoft qui a plaidé pendant 50 longues minutes que Microsoft c’était aussi (et presque surtout) de l’open source et que développer dessus, c’était bien. Apparemment pas assez pour donner envie de poser des questions à l’auditoire.

Bon, ok sur windows, tu peux développer sur Visual Studio 2010 Ultimate, what else?

Du coup un petit sondage a été lancé sur la répartition des OS pour les devs symfony

L’aprèm

Symfony Internals

Pas de nouveautés pour tous les développeurs qui ont pu travailler un peu en profondeur sur ce framework. Une belle revue de tout le fonctionnement interne de Symfony par Geoffrey Bachelet, et avec un accent so french ;)

Voir les slides

Doctrine migration

Un bon rappel sur l’enjeu des migrations et que maintenant (depuis sf 1.3) cela consiste en 3 opérations :

• Modifier son schema.yml pour inclure nos modifications
• Lancer la task de diff:
  symfony doctrine:generate-migrations-diff
• Regénérer ces classes model/form/filter et lancer la migration:
  symfony doctrine:build --all-classes --and-migrate

Alors pourquoi s’en priver?

Voir les slides

Doctrine 2

Est arrivé le tour de chauffe des gros sujets de la conférence. En l’occurrence Doctrine 2. Les grandes idées que Jonathan nous a montré:

• 100% réécrit, donc plus de compatibilité descendante
• ~ 3 fois plus rapide que Doctrine 1.2
• Principalement concentré sur la perf, et donc adieu la magie des findByMaColonne et consor. A l’image de Propel, les getteur et setteur seront générés dans la class model vu que les modèles justement n’hériteront plus d’une class de type Record, permettant ainsi d’alléger la charge mémoire
• Intégration d’une classe qui s’occupera, à l’image du monde java, de gérer les flush et clear. Ca ne sera plus l’objet en lui même qu’il faudra « save » mais demander à cette nouvelle classe de le faire.

Forcément, ca fait un peu peur, car au delà, d’une réécriture, ce sont des gros changements. Mais dans un souci de performance (aussi bien en terme de temps d’exécution que de charge mémoire), on prend le bon chemin. Même si la magie va disparaître…

Voir les slides

Offline admin generator

Sur cette partie, on a retrouvé Thomat Parizot, de chez clever-age (vous savez ceux qui ont annoncé un plugin de gestion de media au dernier symfony live, mais qu’on attend toujours :p).
On découvre un concept plutôt innovant dans le monde symfony, l’idée de permettre l’accès et le travail sur un backoffice sans connexion Internet semble une bonne idée. Il suffit de synchroniser, après coup, son travail.

Bon ok la démo n’a pas été parfaite – ahh l’effet démo – mais ya quand même un gros boulot derrière même si malheureusement c’est un concept très (trop?) dépendant de la technologie, vu qu’après Gears, il se base maintenant sur HTML5 et toutes ces nouvelles fonctionnalités. Donc très limité, mais à garder sous le coude.

Help the community

Skoop a redonner toutes les clés pour aider la communauté. Et que même les petites actions, comme les ouvertures de bug, sont très appréciées.

Voir les slides

Table ronde avec la core team

Pas mal de questions sur les sujets classiques, hello world application, et consor. Voici un petit recap des questions que j’ai comprises et trouvées intéressantes:

Q: Compatibilité descendante avec la fin du support de la 1.0

R: Gros effort sur la facilité de passer à une version supérieure

Q: Documentation du système de form un peu en retrait?

R: Ne pas hésiter à aider!

Q: Symfony enseigné à l’école? Support de cours disponibles?

R: PHP déjà peut enseigné de base. Pas plus d’info à ce sujet mais ne pas hésiter à les contacter sur ce sujet

Q: Développement ne va pas trop vite?

R: La 1.4 aura bien 3 ans de support, ce qui est en soi, très long. Et puis le web évolue vite, donc il faut suivre

Q: Performance? Quid?

R: Le problème vient rarement du framework… :D

Q: Difficulté à faire adopter Symfony par leur client

R: C’est ensemble et en fournissant des cas d’utilisation précis de Symfony, qu’on pourra faire évoluer les mentalités

Q: Sismo? Bientôt dans les bacs?

R: Fabien n’a plus le temps pour l’instant. Projet en standby et clairement pas prioritaire. Et de toute façon Sismo ne fera jamais tout ce que fait Hudson et consor. Il n’a pas écarté la possibilité de ne jamais le release…

Q: Quid de la construction d’un vrai CMS Symfony une bonne foi pour toute?

R: Déjà 3 CMS existant très solides, avec 3 approches différentes. Il faut en débattre.

Q: Pourquoi reprendre plein de projets, comme Swift?

R: Une volonté de ne pas réinventer la roue et de récupérer et adapter les meilleurs pratiques et idées en PHP

Q: Et Propel dans tout ça?

R: Gros boulot de François, mais peut-être un peu trop tard? Jamais dire jamais, mais pour l’instant après le gros switch vers Doctrine, difficile de faire machine arrière. Surtout que le futur de Propel avec sa 2.0 n’est pas du tout assuré pour l’instant

Et du coup, quelques annonces sont sorties:

• phpbb4 sera codé en Symfony 2, ce qui en ferait le premier gros projet open source php entièrement en Symfony si je ne m’abuse
• Symfony2 n’a plus de plugin mais des bundles…
• Symfony2 n’utilisera plus que le meilleur des autres framework, comme le logger et le cache de Zend, au lieu de le recoder de leur côté.

Voilà un petit compte rendu, les slides des différentes interventions sont disponible sur le blog de Symfony.

Vos envoyés spéciaux pour l’évènement: Vince et Tim

crédit photo: http://www.flickr.com/photos/iph4n70m/4338366087/

Du coup, la question qui s’impose c’est, est-ce que certains d’entre vous trouverez sympa d’avoir la traduction d’un de ces articles (à raison d’un par semaine grand max hein)? Voilà, c’est dit, à vous de jouer et de me dire, histoire que je me tracasse pas pour rien.

Pour vous aider à réfléchir, voici la liste de la semaine:

• Evolution de l’interface admin de WordPress
  Petit billet sympa qui retrace grâce à différent screenshot, l’évolution de l’interface admin de WordPress, pour ceux qui ne blog pas depuis 6ans.
• Collez vos pieds de page en bas
  C’est un des détails que les graphistes aiment, mais que les intégrateurs ont vite dégagé, pouvoir collé le footer d’une page en bas du navigateur et ce même si le contenu fait la moitié de la fenêtre. Il y a des solutions JS qui existe, en voici une pure CSS, qui demande juste quelques contraintes pour fonctionner. Pour la plupart des cas, ca ne devrait pas poser de souci.
• Les 100 plugins wordpress les plus populaires
  On a souvent du mal à s’y retrouver dans les plugins wordpress, tellement il y en a et tellement la zone qui leur est réservée sur le site officiel est pas top. Voilà donc une liste qui s’avère pratique où on mentionne tous les leaders pour chaque fonction qu’on souhaite rajouter à notre blog préféré.
• Librairie de cryptage en javascript
  Voici une petite librairie sympa vu qu’elle propose un premier niveau de sécurité au niveau des formulaires html, en cryptant leur envoi au serveur. Bien sûr, cela reste très rudimentaire dans une grosse politique de sécurité, mais l’initiative est bonne et dans certains cas, ne serait-ce que pour compliquer le snif de requête, elle peut s’avérer utile
• Paypal va s’ouvrir aux développeurs
  Je n’ai pas eu le temps d’enquêter plus que ça, donc je vous met le lien d’origine où j’ai trouvé l’info. Mais ca promet!
• Améliorer l’expérience utilisation avec des détails
  Une petite astuce toujours dans la quête de la meilleur expérience utilisateur. Le principe est simple, bien faire comprendre à votre utilisateur que vous avez reçu sa demande.
• 6 choses que votre mère ne vous a jamais dit sur le debug javascript
  Article très sympa, et se serait lui qui serait traduit cette semaine, si jamais vous décidiez qu’il faut que je le fasse.
• Un enième plugin jquery slideshow
  Au royaume du jquery, les slideshow sont rois. On ne compte plus le nombre différentes de plugins qu’il existe. Alors pourquoi je vous parle de celui-là? 2 particularités, il gère la roulette pour le défilement mais surtout il est francophone : )) Et oui quand je trouve de la qualité dans notre belle langue, je me gène pas

Et bien sûr, stay tunes cette semaine, au cas où vous croiseriez un nouveau thème dans le coin… ou pas :p

Alors bien sûr, la solution radicale, c’est de réduire le nombre de colonnes, mais souvent le client, il les veut ses colonnes! La 2e solution est de supprimer ce bloc de filtre. On fait ça très simplement dans le generator.yml:

filter:
  class: false

Cependant, il arrive quand même que le filtrage soit nécessaire mais bien souvent, seulement 2 ou 3 valeurs. J’ai donc décidé de prendre le taureau par les cornes et faire la modification dont je rêve depuis longtemps, passer ce bloc de filtre, au dessus du tableau! Pour ce faire, j’ai modifié 2 fichiers. Tout d’abord, le fichier _filters.php qu’il faudra rajouter dans le dossier templates de vos modules visés:

<div class="sf_admin_filter">
 
	<div class="content_filter">
  <?php if ($form->hasGlobalErrors()): ?>
    <?php echo $form->renderGlobalErrors() ?>
  <?php endif; ?>
 
 
  <form action="<?php echo url_for('produits_collection', array('action' => 'filter')) ?>" method="post">
	  <?php foreach ($configuration->getFormFilterFields($form) as $name => $field): ?>
	  <div class="bloc_filter">
        <?php if ((isset($form[$name]) && $form[$name]->isHidden()) || (!isset($form[$name]) && $field->isReal())) continue ?>
          <?php include_partial('produits/filters_field', array(
            'name'       => $name,
            'attributes' => $field->getConfig('attributes', array()),
            'label'      => $field->getConfig('label'),
            'help'       => $field->getConfig('help'),
            'form'       => $form,
            'field'      => $field,
            'class'      => 'sf_admin_form_row sf_admin_'.strtolower($field->getType()).' sf_admin_filter_field_'.$name,
          )) ?>
    </div>
    <?php endforeach; ?>
 
     <?php echo $form->renderHiddenFields() ?>
     <?php echo link_to(__('Reset', array(), 'sf_admin'), 'produits_collection', array('action' => 'filter'), array('query_string' => '_reset', 'method' => 'post')) ?>
     <input type="submit" value="<?php echo __('Filter', array(), 'sf_admin') ?>" />
  </form>
  </div>
</div>

Au final, j’ai simplement supprimé le tableau, par défaut et mis chaque widget dans un div. On obtient donc quelque chose qui change pas vraiment la donne pour l’instant:

Mais en lui appliquant un peu de css:

div#sf_admin_bar {
	float:none;
	margin: 0;
}
 
#sf_admin_bar .sf_admin_filter form div.bloc_filter {
	display:inline;
	padding:0 20px 0 0;
}
 
div#sf_admin_container #sf_admin_bar label {
	display:inline;
	float:none;
	padding:0;
}

On commence à approcher de ce que l’on souhaite:

Maintenant, on habille un peu la chose, histoire de gagner en clarté:

#sf_admin_bar .sf_admin_filter {
	background-color:#FFF;
	margin:12px 0;
}
 
#sf_admin_bar .sf_admin_filter .content_filter {
	border:1px solid #DDDDDD;
	padding:5px;
}

Pour obtenir finalement:

Un dernier détail, le filtre « référence » avec sa colonne « is_empty » casse un peu notre rendu. Personnellement, je ne me sers pas de cette checkbox, on va donc redéfinir notre filtre pour la supprimer dans lib/filters/MonModuleFilters.class.php:

public function configure()
  {
    $this->widgetSchema['reference'] = new sfWidgetFormFilterInput(array(
      'template' => '%input%'
    ));
  }

Et voilà, une jolie barre de recherche beaucoup plus du goût des clients en général :)

Alors bien sûr, cette solution ne fonctionne qu’avec un nombre limité de filtre, sinon on aurait un rendu un peu moins visuel, mais je pense que ça reste toujours mieux que 2 blocs qui se chevauchent.

En effet, on y lit que l’admin generator est i18n ready, en gros que le système de traduction est en place, qu’il ne reste plus que le fichier xliff (le format utilisé pour la traduction dans Symfony) à faire et à placer dans apps/backend/i18n mais aucune ligne qui semble indiquer que les plugins sfPropelPlugin et sfDoctrinePlugin intègre déjà les traductions de la plupart des langues. Or c’est le cas!

Du coup, pour traduire un admin generator en français (entendre par là, le rendre par défaut en français), cela prend 3 lignes. Les deux premières à ajouter dans le fichier config/settings.yml

.all:
  .settings:
    i18n:  on      # Enable interface translation. Set to off if your application should not be translated.
    default_culture:        fr       # Default user culture

Puis un lien symbolique à placer:

ln -s /votre/chemin/vers/symfony/lib/plugins/sfPropelPlugin/i18n/sf_admin.fr.xml votre/chemin/vers/votre/projet/apps/backend/i18n/sf_admin.xml

Et voilà, l’affaire est dans le sac, un Back office en français, ce qui fait toujours plaisir à des clients français ;)

Et ca tombe bien, parce que niveau idées tordues, nos chefs de projets ou clients sont rarement les derniers, vous serez d’accord avec moi ;)

Lors d’une présentation d’un back office récemment, on m’a demandé s’il était possible de choisir plusieurs valeurs lors du filtrage (en l’occurence des marques de produits). « Certainement » fut ma réponse, même si j’en avais aucune idée. J’ai donc jeté un coup d’oeil sur cette histoire et c’était finalement l’histoire de 2min.

Par défaut, on avait donc:

Sachant que les valeurs de ce filtre allait être limitée, une dizaine à tout casser, j’ai choisi de transformer le widget en liste de checkbox. Je me suis rendu dans lib/filter/ProduitsFormFilter.class.php et j’ai simplement rajouter:

public function configure()
  {
    // mid étant la clé étrangère du produit vers la marque
    $this->widgetSchema['mid'] = new sfWidgetFormPropelChoice(array(
      'model' => 'Marques', 
      'multiple' => true,
      'expanded' => true,
    ));
 
    $this->validatorSchema['mid'] = new sfValidatorPropelChoiceMany(array('required' => false, 'model' => 'Marques', 'column' => 'mid'));
  }

En l’occurence, j’ai simplement changé de widget, l’admin generator fait finalement le reste car par défaut la fonction de filtrage est capable de gérer une ou plusieurs valeurs! C’est quand même bien pensé tout ça. Et on obtient donc:

Rien de plus, rien de moins, une modification qui montre à quel point le système de formulaire de symfony croisé à l’admin generator facilite vraiment les choses.

• 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 : )

Voici donc une solution possible et facile à mettre en place en se basant sur le fichier de routing.

En effet, à chaque ajout de module d’admin via la célèbre:

php symfony propel:generate-admin backend MonModel

Le fichier de routing.yml de l’application en question est modifié avec quelque chose qui ressemble à ça par défaut:

offres:
  class: sfPropelRouteCollection
  options:
    model:               Offres
    module:              offres
    prefix_path:         offres
    column:              oid
    with_wildcard_routes: true

J’ai donc fait un petit snippet qui parse ce yml:

class myAdminMenu 
{
  public static function getLinks()
  {
    $array = sfYaml::load(sfConfig::get('sf_app_config_dir').'/routing.yml');
    $links = array();
    foreach ($array as $k => $v)
    {
      // On n'affiche pas les infos présentes par défaut dans le routing
      if ($k != 'homepage' && $k != 'default' && $k != 'default_index')
      {
        $links[] = $k;
      }
    }
    sort($links,SORT_STRING); // On trie par ordre alphabétique
 
    return $links;
  }
}

Et il ne reste plus qu’à boucler dessus dans votre layout.php:

<ul id="menu">
  	<?php foreach (myAdminMenu::getLinks() as $link): ?>
  		<li><a href="<?php echo url_for($link.'/index') ?>"><?php echo ucfirst($link) ?></a></li>
  	<?php endforeach; ?>
</ul>

Bon j’imagine bien qu’il est perfectible au possible surtout si on configure un nom différent du module à la génération du module mais on fera avancer les choses quand le besoin s’en fera sentir.