Ceux qui me suivent sur Twitter ont pu voir que les choses c’étaient un peu compliqués ces derniers temps même si tout est revenu dans l’ordre pour le moment. Le plugin peanutPosts a été ajouté à son propre repository Git et est utilisable en l’état.

Au passage, un grand nettoyage a été effectué sur le repository principal au niveau des branches et le readme a été mis à jour (avec des fautes d’orthographes).

A noter que vous pouvez utiliser ce plugin indépendamment de peanut sans aucun problème puisqu’il n’a que deux pré-requis : sfDoctrineGuardPlugin (version officielle) et sfDoctrineActAsTaggablePlugin.

Le validateur du formulaire de contact sfValidatorSimpleCaptcha a également son repository et sera prochainement remplacé sur le formulaire de contact par un autre validateur sfValidatorHiddenCaptcha.

Et pour finir, parce que je ne le dirait jamais assez, Symfony est un régal à pratiquer ! A bientôt !

Itération 7 cette semaine avec la création de la branche peanutPosts. Cette branche contient non pas un mais trois modules qui sont en cours de préparation :

• Le module peanutCategories : gestion des catégories
• Le module peanutPosts : gestion des articles dynamiques
• Le module tag : via le behavior Taggable

Il y a donc pas mal de travail à faire et tout avance au fur et à mesure dans l’ordre précédent. La création de ce module m’a également permit de découvrir le behavior Doctrine nestedSet permettant de gérer un arbre et ainsi éviter beaucoup de problèmes de récursivité (avec une gestion des catégories plus classique). Je compte d’ailleurs bien utiliser ce behavior sur le module peanutPage lors de sa refactorisation

Cette itération a également connue un petit bug avec le module Doctrine sfGuardForgotPassword alors vous pouvez remercier tight qui a apporté une réponse au ticket de bug.

La semaine dernière, un site de présentation a été mis en ligne à l’adresse suivante http://www.peanut.fr. Une personne c’est déjà amusée avec le formulaire de contact et vous pouvez faire de même. Vous n’aurez cependant pas accès au backoffice pour le moment, je l’ouvrirais un peu plus tard sur un site de demo. Ce site sera bien entendu amené à évoluer avec les différents modules.

Et pour conclure, je suis toujours aussi motivé par ce projet alors n’hésitez pas à me faire part de vos bugs ou envie, j’essaierai de faire le plus d’heureux possible !

Pour cette sixième semaine, la fin de la version 1.0 du module peanutPage. Ce module est donc fonctionnel et vous pouvez d’ors et déjà l’utiliser. Un petit passage en intégration (sur un vrai-faux site) m’à même permis d’ajouter quelques fonctions bien utiles pour le commun des mortels.

Avec ce module, le plugin csDoctrineActAsSortable a été ajouté ainsi que le plugin sfCKEditorPlugin.

Quelques ajouts xHTML/CSS ont été faits afin d’améliorer un peu le tout au niveau graphique et rendre le backend un peu plus sexy.

Bonus, le module contact a également été ajouté. Rien de bien exceptionnel à ce niveau puisque le formulaire de contact met tout simplement en place le tutoriel symfony forms in action. J’ai tout de même créé un petit validateur au passage baptisé sfValidatorSimpleCaptcha permettant de valider un captcha simple (sur la base d’un addition avec deux opérateurs).

Le module contact est donc également en version 1.0

Le plus important étant que maintenant, vous pouvez utiliser peanut pour créer un site simple de quelques pages même si cela reviendra à utiliser une grosse berline pour aller acheter votre pain.

Le wiki

J’ai ajouté quelques pages au wiki github afin de vous donner quelques informations sur la suite et le programme en perspective. Si vous repérez des bugs mais que vous ne voulez pas forcément proposer une solution, n’hésitez pas à utiliser la gestion de ticket github. Tout est bon à prendre pour moi avec ce projet.

Modification de l’utilisation de Git

J’ai décidé d’utiliser les submodules git afin de gérer les plugins dans le projet. Les submodules Git sont un peu l’équivalent des externals de SVN. Concrètement cela permet d’ajouter des projets git à l’intérieur même d’un superprojet git et donc de pouvoir faciliter les updates.

Dans notre cas, cela permettra de gérer les plugins du projet en offrant à tous la possibilité de télécharger directement le plugin (ou proposer des modifications) sur le repository associé.

Deux submodules ont été ajoutés pour le moment, symfony et mon fork de sfDoctrineGuardPlugin.

Oups!

J’ai fait une « petite » erreur de manipulation avec mes branches Git suite à l’utilisation des submodules. Git a en effet quelques problèmes pour gérer l’ajout de submodule sur une branche lors d’un checkout sur une branche sans submodules (d’après ce que j’ai compris). Résultat des courses, une fausse manip en essayant de faire fonctionner le tout et ma branche master disparait. Il m’a donc fallu la recréer et… Il faut forger pour être forgeron

Un cours de Git m’attends vendredi soir pour régler les petits problèmes associés à cette erreur (rien de méchant). J’aurais donc tendance à vous conseiller d’attendre samedi pour faire une mise à jour (ou alors de ne pas oublier de créer un répertoire « cache » à la racine du projet. Au passage, peanut sera tagué en version 1 et un site demo sera mis en ligne dans la semaine.

Modification de la roadmap

Etant donné que j’ai besoin d’utiliser peanut pour un projet, je vais un peu modifier la roadmap annoncé la semaine dernière. Le projet va donc évoluer de la façon suivante :

• Création du module peanutCategories
• Création du module peanutPosts
• Création du plugin peanutPosts
• Création du module peanutComments
• Création du plugin peanutComments
• Création du module peanutSEO
• Création du plugin peanutSEO

Si tout se passe bien, le tout devrait prendre de 3 à 4 itérations pour les v1 de ses modules/plugins.

Je passerais ensuite au refactoring/amélioration/debug de l’ensemble des modules. Chacun de ses modules (à travers leurs plugins) auront leurs propres repository Git et seront intégrés sous la forme de submodules dans le projet principal. Cela permettra au passage de pouvoir profiter d’un ou plusieurs plugins de son choix sans utiliser la base (même si certains plugins comme le module peanutSEO seront dépendants d’autres plugins).

Ce sera tout pour cette semaine ! A la semaine prochaine

Et pour rappel, vous pouvez récupérer le projet sur Github.

Cette semaine a permis d’assurer la création du premier « vrai » module pour peanut à savoir le module peanutPage. Ce module a été pour moi l’occasion de me mettre aux tests unitaires. Je dois dire que j’ai vraiment trouvé ça intéressant non-seulement pour les avantages « connus » des tests unitaires mais aussi d’un point de vue intellectuel. Mes tests ne sont pas forcément les plus complets pour le moment mais je pense que tout cela s’améliorera avec mon niveau.

Comme j’aborde le sujet, sachez que je vous encourage à vous lancer dans ce genre de projet. J’ai vraiment appris en 5 semaines un nombre conséquent de nouvelles « choses » et pourtant cela ne va pas encore très loin au niveau des fonctionnalités. Mais voila, cette espèce d’obligation de ne pas livrer à tous le monde quelque chose d’innutilisable aide forcément à faire de son mieux et à respecter les bonnes pratiques dans leur ensemble. Je ne vous parle même pas de l’auto-formation et de la documentation relative à tous ce travail même si cela ne se reflête pas de façon flagrante pour le moment dans le projet. Par contre, c’est une autre histoire au niveau professionnel avec des projets interne techniquement plus solide et abouti (notamment à travers un projet d’extranet dont je suis entrain de créer les bases).

Et je me demande vraiment pourquoi j’ai autant attendu pour me mettre à dev…

Ceci dit, revenons à nos moutons. Pour l’instant le module page est complet au niveau du backoffice (avec la personnalisation des formulaires) et des fonctions ont été créées dans le model (on dit merci au TDD). Un module frontend a été créé mais n’est pas du tout adapté au besoin. Cela viendra dans la prochaine itération.

J’ai un peu affiné mes itérations, un module devrait être livré en deux à trois itérations au minimum (mon emploi du temps profesionnel l’oblige). C’est en tout cas ce qui me parait le plus sage à l’heure actuelle car je mange vraiment beaucoup de documentation en ce moment (petite pensée pour les tests fonctionnels qui arrivent). Cela devrait donc donner quelque chose dans le genre :

• Semaine 1 : Création du module, des fonctions de bases et de la partie administration
• Semaine 2 : Création du frontend et si besoin, ajout de fonctions dans le model
• Semaine 3 : Création du plugin correspondant au module

Au niveau des modules, je part à priori la dessus :

• Création du module page
• Création d’un module contact (avec un formulaire de contact type)
• Création du module post (aka articles/catégories)
• Création du module SEO

Une fois ces modules créés :

• Refactorisation du model et des différentes fonctions afin d’optimiser le tout au niveau technique
• Ajout de fonctionnalités type AJAX pour le backoffice

Et enfin, création de nouveaux modules selon le même principe : commentaires, FAQ… Le projet sera ouvert à ce niveau. Il sera bien évidemment possible de créer son propre plugin pour améliorer peanut. Il faudra également que l’on parle à un moment de la tournure du projet au niveaux des fonctionnalités, il y aura une question ouverte .

Nous pourrons donc considérer que peanut sera d’ici deux semaines utilisable en tant que CMS lite (par exemple 5 pages et un formulaire de contact) même si cela reviendra à sortir la grosse artillerie pour un petit besoin. Une fois les modules post/SEO créé, je m’occuperais de faire tourner mon blog sur peanut histoire d’avoir une démo « live ».

Pour terminer, un petit lien vers un article du blog de n1k0 qui m’a été utile pour ne pas utiliser getInstance dans la gestion I18n des formulaires du backoffice. Un blog incontournable à ajouter à ses flux RSS.

Semaine 3 – template, template, template

La semaine dernière a essentiellement servie à créer le layout du backend. Pas grand chose à dire à ce niveau, j’ai essayé de me faire un peu plaisir avec un peu de CSS3, un peu de jQuery et du xHTML (et oui, pas de HTML5 pour le backend). Je n’ai par contre pas encore pris le temps de valider les pages. Il peut donc y avoir quelques erreurs d’intégration. Le backoffice n’a également pas été testé sur la famille Internet Explorer mais je m’en occuperais dans quelques itérations au maximum car inutile de vous le cacher, mon prochain blog tournera bel et bien sur peanut (quitte à devoir évoluer avec).

Semaine 4 – spéciale sfDoctrineGuardPlugin

Comme je l’avais dis au début du projet, je comptais bien modifier sfDoctrineGuardPlugin. Lors de la création du projet, je suis parti sur la base du trunk de sfDoctrineGuardPlugin qui ajoute certaines fonctionnalités avec deux modules : sfGuardForgotPassword et sfGuardRegister permettant respectivement de récupérer son mot de passe et de se créer un compte.

Malheureusement, les process utilisés lors de ces étapes ne sont pas « corrects » dans le sens ou si effectivement ils fonctionnent, ils ne font pas forcément les choses correctement. Je me suis donc efforcé de modifier ces éléments afin de corriger un peu le tir, tout du moins à mon sens. Rassurez-vous, les modifications ne sont pas nombreuses mais en voici quelques unes.

sfGuardAuth

• Possibilité via le fichier app.yml d’autoriser ou non la connection via le nom d’utilisateur et le mot de passe

sfGuardUser

• Modification du fichier schema.yml afin qu’un utilisateur ne soit pas actif par défaut

sfGuardRegister

• Modification de la route afin de pouvoir gérer le process d’inscription
• Lors de la création de compte, un email est envoyé à l’utilisateur afin de confirmer la création du compte
• Modification du process d’inscription qui va se charger de vérifier certains points importants avant d’activer le compte

sfGuardForgotPassword

• L’email envoyé par défaut indique un délai de 24H pour valider son compte mais le code n’imposait pas de limite et n’enregistrait même pas la limite correctement
• Ajout d’une tache permettant via cronjob de supprimer tous les utilisateurs n’ayant pas validé leur compte

De façon générale - Ajout de traductions (uniquement en français)

Parce qu’il faut tout de même le dire

Ce qui est actuellement en place est bien entendu perfectible. Le process d’inscription par exemple va générer une chaine sha1 basée sur le nom d’utilisateur, son adresse email et le csrf token de l’application et comme vous pouvez vous en douter… Il y a mieux (mais il y a aussi largement pire).

Pour moi, il faudrait créer une nouvelle table permettant de stocker les utlisateurs en cours d’inscription avec une clé unique en base de donnée afin de vraiment garantir la sécurité à ce niveau. L’autre option pourrait être de générer le sha1 sur la base du timestamp de création du compte qui pourrait ainsi (puisque stocké en bdd via created_at) servir de base un peu plus fiable. Autre solution, enregistrer l’utilisateur, récupérer l’objet utilisateur et générer quelque chose d’unique basé sur le salt par exemple.

Ceci dit je préfère attendre quelqu’uns de vos retours et mettre tout ça dans ma todolist pour un (éventuel et certains) refactoring dans le futur.

Autre chose, l’ensemble de ce travail a directement été fait dans le plugin sfDoctrineGuard car cela fais vraiment parti pour moi des fonctions à assurer au minimum et non à rajouter à la volée suivant les besoins de chaques projets (contrairement à la personnalisation des templates par exemple). Vous pouvez donc très bien surcharger ce qui est fait mais par défaut, une personne s’inscrit, reçoit un email de confirmation puis confirme son compte et cela tiens quand même plus la route qu’une inscription directe sans plus de vérification que ça.

Enfin, les tests unitaires ne sont pas complets et il faut vraiment que je m’y mette. Cela me dépasse encore un peu pour le moment. Je vois bien le principe mais je ne sais pas si c’est parce que j’ai l’habitude de chercher à faire tout de suite compliqué mais la… Je ne serais pas contre un petit cours à l’oral avec démo et questions connes en direct.

Ceci dit et si jamais j’arrive (ou nous arrivons via vos éventuelles contributions) à améliorer le plugin sfDoctrineGuard, j’aimerais le proposer afin qu’il soit intégré aux plugins (voir remplacer la version actuelle). Certaines conversations lues sur IRC me font dire que ce ne serait pas une mauvaise chose.

Petit détail d’importance, il faut que vous sachiez que mon anglais est encore moins bon que mon français à l’écrit en ce moment. Si jamais vous voulez modifier ça parce que… Hum… Okay mais bon il y a mieux, n’hésitez pas. Il faudrait également s’occuper de la traduction espagnole (puisqu’il y en a une pour le plugin) pour ne pas faire de malheureux mais la… Je vous laisse faire.

A quoi peut servir peanut actuellement ?

Si jamais vous vous posez la question, peanut peut vous servir (dans l’état actuel) à tout et à rien puisqu’il n’assure rien d’autre que la gestion de vos utilisateurs, groupes et permissions. Il est donc envisageable de faire n’importe quoi autour de ça : Réseau social, trombinoscope, intranet, extranet… Et j’en passe.

J’essaierai de vous donner ce genre d’exemples à chaque itération.

Le débat de la semaine

Le débat de la semaine porte sur la traduction i18n pour les setFlash(). Un gist a donc été créé et de la même façon que lors de la précédente question ouverte, je vous invite à l’enrichir via vos différentes méthodes afin de trouver les différentes façons de faire. Vous en trouverez actuellement trois, plus ou moins sexy mais qui fonctionnent toutes.

A venir

Le premier module du CMS permettant tout simplement de créer des « pages » (comprendre pages dynamiques peu modifiées du type CGU/CGV/…) pour votre site Internet.

Et pour finir

J’ai activé le système de donation sur le projet. A défaut d’aller directement dans mes poches, tout sera stocké sur un compte paypal dédié dans le but de m’offrir certaines formations dispensées par SensioLabs Trainings qui seraient à priori :

• PHP niveau 1 : bases
• PHP niveau 2 : POO
• Symfony 1.4 + Doctrine
• Symfony et REST
• Doctrine

Bien entendu, cela pourra évoluer (je l’espère bien) avec ce projet puisque le but pour moi est de pratiquer encore et encore afin de m’améliorer jusqu’au moment où je pourrais trashtalk sur PHP .

Et pour rappel, un lien vers le projet.

Le contexte

Nous avons une table post dans laquelle nous n’avons pas encore d’articles. On va donc faire les choses simplement sans se poser trop de questions. À la wordpress .

Le code

/lib/model/doctrine/postsTable.class.php

<?php

  class postsTable extends Doctrine_Table
  {

    public function getPosts()
    {
      $t = $this->createQuery('c')
        ->where('c.status = ?', 'publish');

      return $t->execute();
    }

  }

/apps/frontend/modules/posts/actions/actions.class.php

<?php

  /**
   * posts actions
   */

   class postsActions extends sfActions
   {

     public function executeIndex(sfWebRequst $request)
     {
       $this->entries = Doctrine::getTable('Posts')->getPosts();

       $this->forward404Unless($this->entries);
     }

   }
}

Et enfin dans notre template : /apps/frontend/modules/posts/templates/indexSuccess.php

[...]

<?php if($entries) {

  foreach($entries as $entry) { ?>

    <h2><?php echo $entry->getTitle() ?></h2>
    [...]

  <?php }

} else { ?>

  <h2>Oups! Aucun article n'a été trouvé</h2>

<?php } ?>

Le résultat

La première fois que j’ai fait ce code, je m’attendais vraiment à trouver mon « Oups… ». Ca me paraissait logique, table vide, la requête ne peut pas renvoyer de résultats à l’action et donc dans la vue mais non. Toujours et encore toujours du vide et aucun « Oups… ».

Et je ne comprends pas.

Je me suis donc « amusé » (c’est vite dit sur Doctrine) avec un var_dump afin de voir ce qui pouvait bien être stocké dans ma variable $entries. Après avoir décortiqué la soupe issue du var_dump, j’ai pu voir que ma variable contenait un Doctrine_collection vide et donc au final quelque chose « plein de vide ».

C’est donc la que l’on peut commencer à réfléchir.

Version 1 – getFirst

La première solution consiste à tester via Doctrine si il y a au moins un enregistrement :

Dans /apps/frontend/modules/posts/templates/indexSuccess.php

[...]

<?php if($entries->getFirst()) {

  foreach($entries as $entry) { ?>

    <h2><?php echo $entry->getTitle() ?></h2>
    [...]

  <?php }

} else { ?>

  <h2>Oups! Aucun article n'a été trouvé</h2>

<?php } ?>

Version 2 – count()

Seconde solution, compter avec un bon vieux count() en PHP :

Dans /apps/frontend/modules/posts/templates/indexSuccess.php

[...]

<?php if(count($entries) > 0)) {

  foreach($entries as $entry) { ?>

    <h2><?php echo $entry->getTitle() ?></h2>
    [...]

  <?php }

} else { ?>

  <h2>Oups! Aucun article n'a été trouvé</h2>

<?php } ?>

Analyse des versions 1 et 2

Les deux solutions fonctionnent mais la méthode ne me semble pas correcte. Si je donne le tout à intégrateur++ qui peut intégrer n’importe quel template WordPress, saura-t’il faire la même chose avec le mien ?

Réponse négative à mon sens, on ne va pas penser à un count() ou un getFirst() de Doctrine. C’est encore plus vrai dans le sens où venant de cet univers, je n’ai absolument pas pensé à faire cette « opération ». Il faut donc trouver autre chose.

Version 3 – count() dans l’action

<?php

  /**
   * posts actions
   */

   class postsActions extends sfActions
   {

     public function executeIndex(sfWebRequst $request)
     {
       $entries = Doctrine::getTable('Posts')->getPosts();

       if(count($entries) > 0)
       {
         $this->entries = $entries;
       }

       else
       {
         $this->entries = false;
       }

       $this->forward404Unless($entries);
     }

   }
}

Version 4 – count() dans le model

<?php

  class postsTable extends Doctrine_Table
  {

    public function getPosts()
    {
      $t = $this->createQuery('c')
        ->where('c.status = ?', 'publish')
        ->execute();

      if(count($t) > 0)
      {
        return $t;
      }

      else
      {
        return NULL;         
      }

    }

  }

Analyse des versions 3 et 4

Avec ces deux versions, je peux renvoyer NULL et tester ma variable beaucoup plus simplement (et pour tout le monde). La question est donc de savoir si cela doit être fait dans l’action ou dans le model.

J’y ai donc réfléchis un peu et je trouve que le faire dans le model est plus simple car permet également de vérifier le contenu d’une requête plus rapidement et avec moins de ligne de code dans l’action. De plus, on peut mettre en place des tests comme is_object() ou is_null() à tous les niveaux ce qui ne me semble pas plus mal.

Mais vous, qu’en pensez-vous ? Où avez-vous d’autres moyens ?

Le projet et son .gitignore

Je ne suis pas encore un expert de Git mais j’ai essayé de créer un fichier .gitignore qui tienne à peu près la route afin de me permettre ainsi qu’à toutes les personnes qui pourraient utiliser ce projet de ne pas avoir à faire « plus que nécessaire ».

• Les contenus des répertoires /cache/, /log/ et /web/uploads/ sont ignorés
• Le fichier /config/databases.yml a été envoyé mais ne devrais plus l’être afin de ne pas à avoir modifier le mot de passe de connexion à votre base de donnée
• Le fichier /config/properties.ini est dans le même cas que le fichier databases.yml
• Le contenu du répertoire /lib/vendor/symfony/ (oubli à rajouter dans le prochain push)

Viens ensuite une petite subtilité. J’ai pour habitude de créer un lien symbolique /web/sf afin de ne pas avoir à rajouter un alias dans le fichier vhost. Cette habitude a été prise suite à différentes aventures avec certains clients et le fameux « non, je garderai mon serveur actuel et vous allez devoir faire avec ». Pour le coup, cela n’est pas plus mal et j’ai donc conservé cette habitude. Ce lien est donc ignoré.

Ma petite expérience m’a également montrée qu’il était possible après un git merge de devoir refaire un chmod 777 sur les deux répertoires log/ et cache/. Il faudra également faire un php symfony cc et un php symfony plugin:publish-assets afin d’être sur d’éviter tout problèmes. Nous verrons bien dans le futur si ces deux opérations se confirment .

Coté Plugin

Deux plugins ont pour le moment été intégrés. Il y en aura au moins un autre mais j’ai préféré ne pas l’intégrer trop tôt.

sfFormExtraPlugin

sfFormExtraPlugin permet d’ajouter un certains nombre de widgets et validators ainsi que sfFormLanguage afin de proposer un site multilingue. Ce plugin fait pour moi parti du must have à toujours intégrer.

sfDoctrineGuardPlugin

Autre must have, le plugin sfDoctrineGuardPlugin qui permet de gérer utilisateurs, groupes et permissions. Petite nuance, le plugin installé n’est pas celui accessible via le lien Download Package mais est celui du trunk car il apporte de nouvelles fonctionnalités qui sont pour moi indispensable.

Nous verrons cependant qu’il faudra modifier ce plugin afin de changer un peu son fonctionnement mais j’y reviendrais plus tard.

Et maintenant ?

Il faudra tout d’abord commencer par la découpe et l’intégration de la charte du backoffice composé d’un simple layout basé sur l’admin-generator car je ne pense pas aller plus loin à ce niveau pour le moment. Faire le maximum avec l’admin-generator est d’ailleurs un bon exercice

Seconde étape, la mise en place et la modification de sfDoctrineGuardPlugin afin de le compléter ou reprendre certaines parties de son fonctionnement. On verra à ce moment la si j’arrive vraiment à me faire au TDD ou si je commencerai à mettre en place ça pour mon propre code par facilité (et oui).

Peanut, c’est quoi ?

Peanut est mon CMS basé sur symfony (branche 1.4), ce CMS est mon labo/expérience me permettant tout simplement d’apprendre les langages web. Le code de peanut n’est donc pas forcément le meilleur du monde mais compte bien l’être avec le temps.

Ce CMS ainsi que la démarche s’inscrit complètement dans mon apprentissage du « Web » en général. Je compte effectivement me mettre à toutes ces choses que je connais uniquement de nom à travers ce CMS, l’apprentissage par la pratique.

Premier défi pour moi, le TDD ainsi que les tests fonctionnels qui me dépassent encore beaucoup. Viendra ensuite tout ce qui « logistique » à travers l’utilisation de différents types de diagrammes UML ce qui me permettra au passage de m’améliorer au niveau de la gestion de plus gros projets professionnels. Nous verrons donc jusqu’où tout cela pourra me mener.

L’organisation du projet

Le projet sera organisé de la façon suivante :

1. Création de la charte graphique du back-office (utilisant l’admin-generator)
2. Mise en place du coeur (symfony 1.4.x et plugins)
3. Modification de certains plugins afin d’avoir une base saine
4. Création des modules sur la base d’un TDD
5. Transformation d’un module en plugin

Les modules ne seront pas forcément documentés, il se peut d’ailleurs qu’il n’y ai qu’un simple billet annonçant la livraison d’un nouveau module et son fonctionnement. Ce sera à voir suivant le type de module et son utilité.

Cela se fera également selon une démarche XP, le code mis en ligne à travers GitHub ne sera donc pas forcément complet à chaque fois mais sera garanti « en état de fonctionnement ». La démarche XP est donc vraiment une priorité pour moi cette année. Reste à voir comment m’organiser à ce niveau mais les itérations devraient à priori être de deux semaines.

Peanut vs Crumblr

Peanut ne sera absolument pas en concurrence avec Crumblr pour plusieurs raisons. La première étant que je ne suis absolument pas développeur sur le projet Crumblr, vous ne pourrez donc pas retrouver quelque chose ici puis sur Crumblr. Il ne faudra, de la même façon pas s’attendre à des tutoriels expliquant pas par pas le pourquoi du comment mais plus à des questions ouvertes puis la création d’un module et sa livraison avant d’améliorer le tout.

A l’inverse, je pourrais très bien réutiliser du code créé via Crumblr pour l’intégrer. Le sens du projet sera d’ailleurs conservé puisque la façon de travailler sur Crumblr et ici ne sera absolument pas la même. Il me faudra donc bel et bien taper le code moi-même.

Coté licence

Le moteur ainsi que tout ce qui sera publié en relation avec le projet sera sous licence MIT. Pourquoi cette licence ? Tout simplement parce que je ne voulais pas mettre la société dans laquelle je travaille actuellement en porte-à-faux. Le moteur est donc créé sur mon temps personnel et uniquement sur celui-ci. Le code peut être exploité par tous le monde et n’oblige à rien tout en évitant tous débats interne ou externe qui auraient une raison d’être à travers d’autres licences.

Conclusion

Le code sera disponible à tous sur GitHub. J’espère vraiment à travers cette démarche vous intéresser à créer un fork du projet non seulement pour pouvoir (pourquoi pas) utiliser le moteur pour vos besoins personnels mais aussi pour me corriger et me signaler tous problèmes éventuels ce qui me permettra vraiment d’atteindre mon objectif.

Pour terminer avec la présentation, j’espère donc pouvoir livrer à l’issu de ce projet quelque chose de correct et complet (documentation et mise à disposition de tous les diagrammes) qui pourra être utilisé par tous (et au moins par moi). Nous verrons bien si cela sera le cas

Cette article fait suite à trois événements :

• La conférence BeZend et une réflexion sur l’admin-generator
• Un article publié chez Maxime
• Un sujet interne à Crumblr

Comme vous pouvez vous en douter, cet article tournera essentiellement autour de l’admin-generator de symfony.

1. Présentation de l’admin-generator

Faisons simple pour cette explication, l’admin-generator vous permet très simplement via le biais d’une simple commande symfony de créer une interface d’administration pour votre site. Cela se passe de la façon suivante dans votre terminal. Je pars du principe que vous avez déjà généré votre projet et que vous avez déjà construit votre base de donnée, formulaires, votre model…

1.1 Création d’un module avec l’admin-generator

Première étape, nous allons créer une application pour le backoffice :

php symfony generate:app backend

Puis après créer un module géré par l’admin-generator

php symfony doctrine:generate-admin backend matable --module=le nom du module

Et voila, tout est créé. Comme vous pourrez le constater, la démarche est relativement simple. Le résultat obtenu sera proche de l’exemple ci-dessous :

D’autres exemples sur le tutoriel Jobeet

1.2 Les fonctionnalités de l’admin-generator

L’admin-generator vous créer donc une interface graphique complète avec un certains nombres de fonctionalitées attendues dans un backoffice :

• Une interface graphique complète
• Un CRUD complet (Create – Read – Update – Delete)
• Des filtres
• Des actions batchs/lists
• Des messages de validations/erreurs
• Une pagination

Ajoutez ensuite à cette liste la possibilité de personnaliser très simplement les différents éléments de l’interface via un fichier generator.yml.

1.3 Conclusion

Rapidement, nous pouvons tirer une première conclusion : l’admin-generator est très simple de création. Rien à redire à ce niveau.

Mais l’admin-gen est-il une solution idéale ?

2. L’aspet graphique

Une petite pensée pour ce cher LoL Guru

Il est très facile pour une personne technique de négliger un backoffice sur le plan graphique. Personnellement, tous mes backoffice sont accessible par mes clients. Il faut donc pouvoir livrer quelque chose de correct graphiquement à ce niveau et il m’a donc fallu me pencher très rapidement sur ce problème.

Graphiquement, il faut tout d’abord distinguer deux éléments : le template global de l’application et le template de chacun des modules. Il est donc possible dans un premier temps d’appliquer un style graphique via le fichier apps/backend/templates/layout.php. Cela permettra déjà d’offrir une cure de jouvence à l’interface créée par l’admin-generator.

De la même façon, vous pouvez personnaliser l’admin-generator via le fichier apps/backend/config/view.yml en ajoutant un fichier css qui viendrais remplacer certaines propriétés. Par exemple pour déplacer les filtres en haut du document et pour agrandir les champs input text, il vous suffira très simplement d’appliquer les styles suivants :

#sf_admin_bar { float: none; margin: 0 0 20px 0; }
#sf_admin_container input[type=text] {
width: 400px;
}

La encore, rien de bien compliqué. Vous pourrez donc personnaliser un certains nombres d’éléments de cette façon.

2.1 Oui mais moi, je veux vraiment tout personnaliser !

C’est un peu la que tout commence à se gâter. Si l’envie vous prenais de commencer à vouloir personnaliser les templates, vous pourriez vous apercevoir d’une chose : Il n’y a aucun fichier dans le repertoire templates des modules générés.

wow.

Mais ils sont ou alors ?

Et voila, nous venons de poser le doigt sur le principal inconvénient de l’admin-generator. La simplicité a donc bel et bien un revers. Il vous faudra en effet surcharger un certain nombre d’éléments de l’admin-generator pour pouvoir en profiter pleinement. Et pour retrouver tout ses fichiers, il vous faudra aller dans le repertoire cache de votre application et les ouvrir tour à tour pour mettre le doigt sur le contenu de l’élément concerné.

Cela peut être très simple, la personnalisation minimale étant à mon sens étant celle du fichier generator.yml dans le module concerné afin de réorganiser l’affichage.

Autre exemple avec un plugin must-have. Pour personnaliser le formulaire d’authentification de sfDoctrineGuardPlugin, il vous faudra créer un répertoire templates dans un module sfGuardAuth pour enfin faire un fichier signinSuccess.php qui vous permettra de reprendre le code.

Heureusement pour nous, il existe une liste de tous les templates utilisés :

• _assets.php Rendre lees CSS et les JS pour les utiliser dans les Templates
• _filters.php Rendre la zone des filtres
• _filtersfield.php Rendre un seul champ du filtre
• _flashes.php Rendre les messages flash
• _form.php Afficher le formulaire
• _form_actions.php Afficher les actions du formulaire
• _form_field.php Afficher un seul champ du formulaire
• _form_fieldset.php Afficher un jeu de champs du formulaire
• _form_footer.php Afficher le formulaire pied de page
• _form_header.php Afficher le formulaire d’entête
• _list.php Afficher la liste
• _list_actions.php Afficher les actions de la liste
• _list_batch_actions.php Afficher les actions batch de la liste
• _list_field_boolean.php Afficher un seul champ booléen dans la liste
• _list_footer.php Afficher le pied de page de la liste
• _list_header.php Afficher l’entête de la liste
• _list_td_actions.php Afficher les actions d’un objet pour une ligne
• _list_tdbatchactions.php Afficher le checkbox pour une ligne
• _list_td_stacked.php Afficher le layout stacked pour une ligne
• _list_td_tabular.php Afficher un seul champ pour la liste
• _list_th_stacked.php Afficher un seul nom de colonne pour l’entête
• _list_th_tabular.php Afficher un seul nom de colonne pour l’entête
• _pagination.php Afficher la pagination de la liste
• editSuccess.php Afficher la vue edit
• indexSuccess.php Afficher la vue list
• newSuccess.php Afficher la vue new

Cela représente donc un certain nombre de fichiers et il vous faudra prendre en compte la problématique qui pour faire simple sera la suivante :

• Est-ce que j’ai un ou plusieurs templates à surcharger ?
• Est-ce que cette modification est redondante à l’ensemble des modules ?

Enfin et pour conclure avec cette partie, ce travail de personnalisation complète du backoffice n’est fondamentalement pas plus complexe que pour le backoffice d’un Joomla, d’un Drupal, d’un WordPress et j’en passe. Si vous savez intégrer pour votre front-office, vous saurez le faire pour le back-office.

3. Coté code maintenant

N’y allons pas par quatre chemins, la encore vous aurez le bonheur de trouver des fichiers actions.class.php complètement vide qui vous permettront de surcharger tout ce que vous pourrez retrouver dans les fichiers stockés dans le cache.

La liste complète des actions est la suivante (attention les traductions sont un peu aléatoires ) :

• executeIndex() Action de la vue list
• executeFilter() Mettre à jour les filtres
• executeNew() Action de la vue new
• executeCreate() Création d’un enregistrement
• executeEdit() Edition d’un enregistrement
• executeUpdate() Mise à jour d’un enregistrement
• executeDelete() Supprimer un enregistrement
• executeBatch() Executer une action batch
• executeBatchDelete() Executer l’action batch _delete
• processForm() Processer le formulaire emploi
• getFilters() Retourner le filtre actuel
• setFilters() Définir le filtre
• getPager() Retourner la pagination de la liste
• getPage() Obtenir la page de la pagination
• setPage() Définir la page de la pagination
• buildQuery() Construire la requête pour la liste
• addSortQuery() Ajouter la requête de tri pour la liste
• getSort() Retourner la colonne triée actuelle
• setSort() Définit la colonne triée actuelle

La encore, beaucoup d’éléments à prendre en compte.

3.1 Les formulaires et relations

Qui dit backoffice dit interraction avec la base de donnée et donc beaucoup de formulaires ce qui me permet de répondre à l’une des plus belles idioties entendue au Be-Zend sur l’admin-generator : Non, un module créé avec l’admin-generator n’intérragie pas forcément avec une seule des tables de votre base de donnée. Je tairais même le nom de l’auteur de cette remarque afin de préserver sa réputation (jusqu’à ce que les vidéos arrivent).

Créer un module via la commande doctrine:generate-admin c’est très basiquement créer un module avec un template généré et des fonctions prédéfinies. Vous pouvez donc intéragir de la même façon qu’avec un module classique et vous pourrez avec un seul formulaire “en apparence” travailler avec un nombre X de tables avec autant de formulaires. Je vous conseille d’ailleurs d’aller lire un article de Niko expliquant les embedForms et embedRelations.

Un embedForm pourra donc être intégré via le generator.yml en l’appelant tout simplement par son nom. Tous les champs seront appelés et vous pourrez très simplement les exploiter. Une même page d’édition/création pourra par exemple vous permettre de travailler sur votre table post et votre table seo pour une plus grande souplesse. La limite étant uniquement humaine : est-ce que vos formulaires à ralonge ne vont pas déstabiliser l’utilisateur ? (ce qui sera d’autant plus vrai dans le cadre de l’utilisation de plusieurs langue via I18n)

Inutile de le préciser, l’ensemble des champsdes formulaire sont bien évidemment personnalisable via les fichiers correpondant dans /lib/form/doctrine/xxxForm.class.php

3.2 Les actions batch et list

La encore, tout est très simple. Nous retrouvons vraiment une philosophie symfony dans l’admin generator. Créer une action batch/list consiste donc en un minimum de deux étapes :

1. Ajout d’un batch dans le fichier generator.yml
2. Création de l’action correpondante dans le fichier actions.class.php de type : public function executeBatchXXX(sfWebRequest $request) { } OU public function executeListXXX(sfWebRequest $request) { }

Cerise sur le gateau, le code que vous ferez à travers vos batchs/lists pourra être utilisé pour créer une tache symfony avec très peu de code à modifier. Cela permettra par exemple de pouvoir appeler une tache automatiquement via Cron tout en offrant la possibilité à l’utilisateur de faire la même chose via une action batch/list.

3.3 Et ce n’est pas fini

Vous pouvez rapidement faire un tour de l’ensemble des possibilités dans le chapitre dédié à l’admin-generator du tutoriel Jobeet.

4. Alors l’admin-generator killer admin ?

Par moments oui tandis que d’autres non.

Comme vous avez pu le remarquer, un nombre conséquent de possibilités sont facilement accessible via l’admin-generator mais cela implique un nombre plus ou moins important de changements. Il faudra donc avant tout chose peser le pour et le contre vis à vis du projet.

• A quoi va me servir l’admin-generator (interaction complète avec le front comme un CMS ou partielle comme Jobeet par exemple)
• Quel va être le niveau de personnalisation graphique ?
• Quel sont les attentes en terme de fonctionnalités à surcharger ?

Les réponses à ces différentes questions vous permettront d’établir un pourcentage variable allant (à mon niveau) de 10% à presque 70% d’éléments à surcharger. L’utilisation de l’admin-generator doit donc être un élément réfléchi dont il faut peser l’impact et penser l’utilisation. Dans le cadre d’applications simples, l’admin-generator sera un outil idéal vous permettant de gagner énormément de temps mais si vous devez commencer à ajouter des fonctionnalités importantes ou de l’AJAX par exemple, les surcharges pourront devenir très importantes et le routage pourra même être impacté. Dans ce cas, un backoffice créé de toute pièce sera donc plus adapté.

Quant à la mixité admin-generator/module classique, j’ai un peu de mal à y croire car il faudra expliquer les différences graphiques entre les templates maison et ceux générés. Pour mettre à niveau le tout, il faudra donc prévoir la personnalisation de l’ensemble et donc la encore un certain nombre d’heures de travail.

Quoi qu’il en soit, l’admin-generator n’est pas à sous-estimer car il peut rendre service dans de nombreux cas en vous permettant de gagner énormément de temps. Après tout, c’est exactement ce à quoi il destiné.

Long moment d’absence sur ce blog (et les autres) mais l’envie commence à revenir alors autant en profiter. Pour ce (re)nouveau premier billet, un petit récapitulatif de l’année 2009, un petit topo concernant les projets en cours pour terminer avec un peu d’avenir.

En 2009, je suis développeur web

Ceux qui connaissent mon parcours savent que si j’en suis venu au web, c’est surtout grâce à de bonnes rencontre et un peu de travail personnel. Pendant environ deux ans, je me suis cantonné au rôle d’intégrateur touche à tout. Tour à tour intégrateur, webdesigner ou encore développeur WordPress (et blagueur) je n’ai que peu touché au développement « from scratch ». A la mi 2009, tout à changé et j’ai créé mon premier fichier avec l’extension php. Tout seul. Comme un grand.

Alors avant d’aller plus loin, quelques remerciements. C’est Romain aka Palleas qui ouvre le bal car c’est vraiment lui qui m’a supporté au début. Viens ensuite indirectement Hugo à travers son site pour débutant apprendre-php.com et le duo Joris/Mehdi via leurs différentes relectures/debug/conseils sur quelques pastie.

A tout ça c’est rajouté différents ouvrages : PHP5 avancé, PHP5 cours et exercices et PHP5 Best Practices. Je pense d’ailleurs prendre quelques actions chez Eyrolles.

L’apprentissage c’est déroulé de la façon suivante : Il y avait un besoin client auquel je ne pouvais pas répondre via les différentes solutions CMS existentes. Quelque chose qui devait être « from scratch » et un contexte qui rendait impossible la sous-traitance. C’est donc ce besoin qui après un bon paquet de bonnes excuses a été le déclencheur. Paradoxalement, j’ai tout de suite écarté les frameworks car j’avais peur de ne pas pouvoir comprendre leurs fonctionnement et passer trop de temps que je n’avais pas sur une problématique.

La démarche à donc été ma démarche habituelle :

• Trouver un maximum de ressources pertinentes afin de cibler directement les bonnes pratiques
• Segmenter l’application en différentes parties et trouver une solution aux différents problèmes
• S’appuyer sur des projets existants, notamment au niveau de l’organisation des fichiers et les différents appels entre les fichiers afin d’optimiser au maximum

Cela a rapidement donné une première version. Trop chaotique à mon gout qui n’est jamais sortie de l’environnement de développement. Une seconde version à donc été faite en prenant quelques bonnes idées issues du Zend Framework. Le moteur était donc plus souple et ouvert à de nouvelles fonctionnalités ce qui a permit de créer l’application complète avec des process métiers cohérents. Ceci dit, il était encore perfectible.

La v3 du moteur est donc arrivée peu de temps après avec pour objectif d’exploiter la POO au maximum. Après quelques lignes de codes, je me suis surtout rendu compte d’une chose : il était complètement stupide de faire cette v3. Cette v3 aurait effectivement eu un sens si l’objectif avait été celui de réinventer la roue pour mieux la comprendre mais ce n’était pas le cas. J’ai donc commencé à benchmarker quelques frameworks.

Fin Aout, le choix était arrêté : Symfony. Ce choix a essentiellement été fait grâce au bien connu Jobeet, tutoriel d’apprentissage du Framework. A noter qu’à la même époque, la ferme du web débutait la publication de son application Watch My Desk. L’idée de pouvoir exploiter d’autres framework, notamment Zend de façon simple et pertinente a également été un gros plus.

L’apprentissage à cependant été difficile, beaucoup d’éléments à prendre en compte dès le début : la philosophie MVC en tête qui est déstabilisante au début mais dont je n’arrive plus à me séparer. Viennent ensuite la syntaxe Doctrine aka DQL et le Yaml (notamment au niveau de la création de la base). Cela c’est somme toute bien passé puisque je travail actuellement uniquement avec symfony et certains composants du Zend Framework.

Depuis la fin Septembre, beaucoup d’apprentissage sur symfony et surtout, surtout, beaucoup de refactoring

En 2010, je suis Chef de Projet

Car après tout, c’est encore l’intitulé sur ma feuille de paie.

L’étape 2009 a donc permis de créer une base suffisamment fiable et une série de plugins permettant de répondre à 3/4 des besoins de mes clients et me contenter de refactorer mon code dans le but de l’optimiser. Je peux donc me dégager du temps pour reprendre les process et la démarche web de l’entreprise dans le but de la perfectionner.

Le fonctionnement et la taille de la société étant tout à fait adapté à l’eXtreme Programming, je suis entrain de tourner toute l’approche dans ce sens. Le but étant de commencer à proposer une approche agile d’ici environ un à deux mois.

Ceci dit, il ne faut pas s’endormir sur ses lauriers alors…

En 2010, de nombreux projets personnels

Crumblr : Cooking for developers

Certainement LE projet 2010, Crumblr est né suite à série de constats professionnels et des réflexions communes entre Romain, Xavier et moi. Avec un peu de recul, nous nous sommes bien rendu compte que finalement peu de personnes arrivaient à se rendre compte des différents aboutissants du projet. Si je devais les résumer dans les grandes lignes, cela donnerai à peu près ceci :

• Guider un débutant à travers une suite de tutoriels pertinents
• Aiguiller le professionnel en lui montrant des applications/technologies concrètes répondant à un réél besoin client
• Expliciter les différentes approches web : philosophie de travail, bonne pratiques, réutilisabilité du code, …
• Ouvrir à tous les professionnels du métier la possibilité de créer un tutoriel ou même de reprendre une partie déjà publiée dans le but de l’améliorer aussi bien au niveau code qu’au niveau des fonctionnalités
• Ne surtout pas faire le travail à votre place car cela ne vous servirait absolument pas sur le long terme

Le dernier point est d’importance, il sera en effet impossible de télécharger les sources des projets car la réflexion de base nous a directement fait remonter l’un des points les plus importants : rien ne vaux la pratique. Un « feignant » devra donc au minimum copier/coller l’ensemble du code publié dans les tutoriels pour arriver à son objectif. Cela devrait donc contribuer à son apprentissage en espérant que l’envie de commencer à développer  »correctement » le démange assez vite. Quitte à ce que ce soit sur un second projet.

D’un point de vu personnel, le projet est pour moi le parfait petit labo me permettant d’essayer différentes choses correctement et trouver un juste milieu entre l’idéal professionnel et la réalité du terrain. Mon coté multi-tache me permettra également de pouvoir aider sur à peu près tous les postes ou presque ce qui permettra également de me perfectionner.

Tous les « a cotés »

Plusieurs projets personnels à coté de tout ça. Ces projets auront pour but de continuer à me faire progresser en développement tout en mêlant utile, agréable et surtout fun (moteur essentiel en ce qui me concerne au cas ou vous ne l’auriez pas encore remarqué). Il y aura donc la refonte de tous mes blogs autour de symfony, un projet fun et un petit réseau social pour la famille (hellotipi like) au programme de 2010 si le temps me le permet. J’ai beaucoup de progrès à faire au niveau des tests, tous ces projets devraient donc être en TDD.

Et ce blog ?

Le constat est le suivant : je n’ai pas le temps pour le mettre à jour au niveau « technique » à proprement parlé. Tout ce qui serait commencé ici serait donc plus ou voué à s’étaler sur une période plus ou moins longue voir même ne jamais être terminé.

Je pense donc réorienter ce blog autour de réflexions techniques sans pour autant négliger deux trois bouts de codes quand le coeur m’en dira. Un certains nombres de réflexions devraient donc être abordées ici afin de laisser la place au dialogue dans les commentaires avant d’être appliquées sur Crumblr. Les deux blogs seront donc pour moi un parfait complément sur le plan professionnel et personnel.

Ne reste plus qu’à savoir si je m’y tiendrais… Ceci dit le nombre de fautes que je fais actuellement commence sérieusement à m’énerver et écrire comme je le faisait avant est donc un parfait remède au problème alors…