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.

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 ?

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é.

Heureusement, tout à une fin alors aujourd’hui nous parlerons de l’installation complète d’un serveur d’environnement de développement sur Mac. Ce tutoriel se base sur la dernière version de chacun des logiciels et vous expliquera step-by-step comment installer et configurer votre serveur afin d’obtenir un environnement sain en évitant le maximum de manipulations.

Pré-requis

Le système d’Apple n’ayant pas de gestionnaire de package digne de ce nom, le pré-requis indispensable est l’installation de macports. Il vous faudra télécharger le programme correspondant à votre système qui vous demandera lui-même d’installer Xcode afin de pouvoir compiler tous les binaires.

Première étape : La mise à jour de MacPort

Une fois MacPort installé, la première étape consiste en la mise à jour du programme. Pour cela, rien de bien compliqué puisqu’il vous suffira de taper la commande suivante :

sudo port selfupdate

MacPort devrait se mettre à jour ainsi que sa liste de package. Cela permettra de pouvoir mettre en place les dernières versions des différents serveurs.

Seconde étape : Installation d’Apache

Passons à l’installation d’Apache, à partir de ce moment soyez un peu patient car l’installation ne se fait pas forcément en 5 minutes alors prenez une bière (ou un coca) et profitez un peu des flocons de neige en hiver ou de votre voisine en maillot de bain en été.

sudo port install apache2
sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

Troisième étape : Installation de MySQL

MySQL maintenant, un peu plus d’étapes de configuration mais cela devrait plutôt bien se passer.

sudo port install mysql5-server
sudo -u mysql mysql_install_db5
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist
/opt/local/lib/mysql5/bin/mysql_secure_installation

La dernière commande vous invitera à rentrer votre identifiant et mot de passe, soyons clair, même en environnement de développement, il faut toujours un mot de passe à votre compte root. Vous pourrez au passage supprimer les tables test lorsque le script vous le demandera.

Quatrième étape : Installation de PHP

L’étape qui fait mal puisque la moins bien documenté pour MacPort depuis le changement de version. Heureusement tout devrait bien se passer pour nous. Tous les modules que vous allez installer dans la suite ne sont pas forcément indispensables mais disons que vous serez bien équipé pour la suite.

sudo port install php5 +apache2 +pear
sudo port install php5-mysql
sudo port install php5-eaccelerator
sudo port install php5-exif
sudo port install php5-gd
sudo port install php5-gettext
sudo port install php5-iconv
sudo port install php5-imagick
sudo port install php5-mbstring
sudo port install php5-mcrypt
sudo port install php5-openssl
sudo port install php5-sqlite
sudo port install php5-xmlrpc
sudo port install php5-xsl
sudo port install php5-zip

Configuration de PHP

Maintenant que tout est installé, l’étape de configuration grâce à laquelle nous allons pouvoir bientôt travailler.

cd /opt/local/etc/php5/
sudo cp php.ini-production php.ini

Pourquoi copier le fichier php.ini de production ? Tout simplement car c’est le plus restrictif et je préfère pour ma part modifier un fichier restrictif qu’un fichier de configuration trop permissif. Travaillant en plus avec Symfony, je n’ai pas trop à me soucier de ça

Nous allons donc éditer notre fichier php.ini. Il vous faudra rechercher la ligne suivante, j’utilise pour ma part vi dont voici les commandes principales :

Ouvrir un fichier : vi <nom du fichier>
Rechercher dans le fichier : <appuyer sur echap puis faire> /<occurrence à rechercher>
Editer un fichier : <appuyer sur la touche i>
Enregistrer un fichier : <appuyer sur echap puis faire>:w
Quitter un fichier : <appuyer sur echap puis faire>:q
Forcer un quit sur un fichier modifié : <appuyer sur echap puis faire>:q!

sudo vi /opt/local/apache2/conf/httpd.conf
<Rechercher> DirectoryIndex index.html
<Modifier par> DirectoryIndex index.php index.html
 
<Rechercher>Include conf/extra/
<Ajouter>Include conf/extra/mod_php.conf
<Enregister>
 
sudo vi /opt/local/etc/php5/php.ini
<Rechercher>mysql.default_socket
<Modifier par>mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock
 
<Rechercher>mysqli.default_socket
<Modifier par>mysqli.default_socket = /opt/local/var/run/mysql5/mysqld.sock
 
<Rechercher>pdo_mysql.default_socket
<Modifier par>pdo_mysql.default_socket = /opt/local/var/run/mysql5/mysqld.sock
 
<Rechercher>date.timezone
<Modifier par>date.timezone = Europe/Paris
 
<enregister>
sudo /opt/local/apache2/bin/apachectl -k restart

Votre environnement devrait être prêt !

Création d’un fichier phpinfo

sudo vi /opt/local/apache2/htdocs/phpinfo.php
<Ajouter><?php phpinfo(); ?>
<Enregister>

Votre fichier devrait être accessible à l’adresse http://localhost/phpinfo.php Vous pourrez à ce moment la vérifier vos différents modules et vérifier que vos drivers mysql fonctionnent correctement (ils devraient apparaitre dans la liste, recherchez simplement « pdo »).

Installation de phpMyAdmin

Afin de faciliter votre maintenance MySQL, installons phpMyAdmin.

sudo port install phpmyadmin
sudo vi /opt/local/apache2/conf/httpd.conf
 
<Rechercher>Include conf/extra/
<Ajouter>Include conf/extra/httpd-phpmyadmin.conf
 
sudo vi /opt/local/apache2/conf/extra/httpd-phpmyadmin.conf
 
<Ajouter les éléments suivants>
 
AliasMatch ^/phpmyadmin(?:/)?(/.*)?$ "/opt/local/www/phpmyadmin$1"
 
<Directory "/opt/local/www/phpmyadmin">
  Options -Indexes
  AllowOverride None
  Order allow,deny
  Allow from all
 
  LanguagePriority en de es fr ja ko pt-br ru 
  ForceLanguagePriority Prefer Fallback
</Directory>
 
<Enregister>
sudo /opt/local/apache2/bin/apachectl -k restart

Utilisations de vhosts

N’importe qui vous le dira, les vhosts, c’est le bonheur. Cette étape est cependant facultative. Nous allons donc mettre le tout en place pour en bénéficier.

sudo vi /opt/local/apache2/conf/httpd.conf
<Rechercher> Include conf/extra/
<Ajouter> Include conf/extra/httpd-vhosts.conf
<Supprimer la ligne> Include conf/extra/httpd-phpmyadmin.conf
<Enregister>
 
sudo vi /opt/local/apache2/conf/extra/httpd-vhosts.conf

Nous allons ajouter deux vhosts principaux afin de pouvoir utiliser le répertoire Sites de l’arborescence Mac. Au passage, modifions le vhost pour phpMyAdmin.

Attention, il s’agit de ma propre configuration, à vous de la personnaliser.

<VirtualHost *:80>
    ServerAdmin pocky@pockyworld.com
    DocumentRoot "/Users/Alexandre/Sites/"
    ServerName www.pockyworld.local
 
    <Directory "/Users/Alexandre/Sites/">
        Options Indexes FollowSymLinks Includes ExecCGI
        AllowOverride All
        Order allow,deny
        Allow from All
    </Directory>
 
</VirtualHost>
 
<VirtualHost *:80>
    ServerAdmin pocky@pockyworld.com
    DocumentRoot "/opt/local/www/phpmyadmin/"
    ServerName sql.pockyworld.local
 
    <Directory "/opt/local/www/phpmyadmin">
       Options -Indexes
       AllowOverride None
       Order allow,deny
       Allow from all
 
       LanguagePriority en de es fr ja ko pt-br ru
       ForceLanguagePriority Prefer Fallback
    </Directory>
 
</VirtualHost>

N’oubliez pas de relancer Apache après avoir effectué cet ajout de vhost.

sudo /opt/local/apache2/bin/apachectl -k restart

Le petit plus : Installation de GIT

Le petit extra spécial geek fan du versioning

sudo port install git-core +svn
 
git config --global user.name "Votre nom"
git config --global user.email "Votre adresse mail"

Attention pour Git, tout n’a pas directement fonctionné du premier coup, n’hésitez pas à relancer la commande d’installation.

Conclusion

Votre environnement de travail devrait fonctionner et être idéal pour pouvoir travailler. N’oubliez pas de personnaliser votre fichier de configuration de php (le php.ini) suivant vos besoins. Celui livré par défaut dans ce tutorial n’affichera par exemple pas les erreurs PHP ce qui peut être embêtant en phase de développement .

Vous ne devriez pas (avec les vhosts) avoir de problème d’autorisations d’écriture dans votre répertoire Sites car il est créé par le système lors de l’installation de MacOS. Dans le cas ou vous utilisiez le répertoire par défaut (sans vhost) il vous faudra modifier les autorisations (pomme + i sur le répertoire) pour vous autoriser l’écriture de fichiers.

Qu’est-ce qu’une police exotique ?

Une police exotique est tout simplement une police non-standard. D’accord, vous n’êtes pas plus avancé alors qu’est-ce qu’une police standard ? C’est tout simplement une police présente sur tous les systèmes d’exploitation et prise en charge par tous les navigateurs. La police Arial est une police standard, à contrario la police Helvetica n’est pas une police standard quant à la police Helvetica Neue, ne cherchez pas à la trouver sur un système d’exploitation autre que Mac OS.

En partant de ce principe, le webdesigner et l’intégrateur doivent donc trouver comment faire avec les polices standards et les polices exotiques dans le but d’atteindre le Saint-Graal, un affichage identique sur tous les navigateurs.

Les différentes solutions

Les différentes solutions sont donc relativement simple. Tout d’abord du coté du webdesigner, il faudra faire au maximum avec les polices standards en ne gardant les polices exotiques que pour les éléments « statiques » de votre maquette : logo et navigation par exemple. Seulement cette limite peut être forte pour ceux qui souhaiteraient avoir le titre d’un article affiché avec une police exotique.

Du coté de l’intégrateur maintenant, il faudra faire avec la maquette du webdesigner. Tous les éléments statiques pourront être transformés en images et gérés via les sous propriétés de la balise a : a:link, a:visited, a:hover, a:active, – mémotechnique : LoVe HAte.

Seulement voila, que faire de nos titres utilisant une police exotique et pourtant dynamique ? La aussi plusieurs solutions existent, le remplacement du texte par une image générée via une libraire de type GD ou encore ImageMagick, l’utilisation de propriétés CSS ou encore le recours à Flash et/ou Javascript. Le tout étant de trouver le moyen convenant au maximum de monde.

Écartons directement l’utilisation de GD/ImageMagick, cela implique un peu de travail coté développement et l’intégrateur n’est pas forcément développeur. Au niveau de CSS, @font-face est une solution proposée du coté de CSS3. Enfin, du coté de flash et de JS, beaucoup d’entre-vous connaissent la solution sIFR mais beaucoup d’entre-vous savent aussi que sIFR à quelques problèmes relavant par moment du mysticisme.

Ma solution : CSS3, jQuery et Cufon

Passons maintenant à ma solution, elle utilise CSS3 via @font-face, jQuery pour la détection de la présence des polices et Cufon pour le remplacement. Le but, rendre la chose compatible avec le maximum de navigateurs. Pour les détracteurs, oui, si jamais une personne arrive avec Internet Explorer 6 et le javascript désactivé, cela ne fonctionnera pas.

Première étape : @font-face et CSS3

La première étape de la solution consiste en l’utilisation de @font-face. @font-face est une propriété CSS3, cette première étape ne s’appliquera donc qu’au navigateur supportant cette propriété CSS3.

Pour information @font-face est en fait une propriété CSS 2 complètement délaissé à l’époque de CSS 2.1 puis réintroduite via CSS3.

Nous allons donc prendre notre fichier de police, l’envoyer dans un dossier précis (soyons fou, il se nommera /font/) puis l’inclure dans notre feuille de style de la façon suivante.

@font-face { font-family : 'Ma police exotique';
src: url('font/mapoliceexotique.ttf') format('truetype'); }

Seconde étape, appeler notre police de la façon la plus basique qui soit via la propriété CSS font-family. Nous l’appellerons pour nos titres h3 dans le div avec l’identifiant article.

#article h3 { font-family: "Ma police exotique", arial, sans-serif; }

Seconde étape : cufon

Passons maintenant aux autres navigateurs, nous utiliserons cufon car après beaucoup d’essais en condition de production, cufon est la meilleure alternative à sIFR.

Le fonctionnement de cufon : cufon est composé de deux fichiers, le premier est un fichier yui (interface) chargé de traiter le fichier de police en javascript créé via une interface web. cufon s’implémente via VME sur les vieux navigateurs et via canvas sur les navigateurs plus récents.

Tout d’abord, télécharger le fichier YUI de cufon puis se rendre sur le site internet de cufon afin de générer un fichier javascript de police. Une fois cela fait, envoyer le tout sur votre serveur dans le repertoire de votre choix (disons /js/).

<script src="js/cufon-yui.js" type="text/javascript" charset="utf-8"></script>
<script src="js/mapoliceexotique.font.js" type="text/javascript" charset="utf-8"></script>

Troisième étape : jQuery

Une fois l’étape 3 terminée, nous pourrions très simplement nous arrêter la mais cela serait un peu bête car l’étape 1 n’aurait donc aucun sens. Nous allons donc très simplement utiliser notre ma librairie javascript favorite à savoir jQuery ainsi qu’un plugin pour tester la présence du fichier de police sur l’ordinateur du visiteur.

Pour cela télécharger jQuery (si vous ne l’utiliser pas déjà pour tous vos effets javascript) puis le plugin fontavailable. Enfin, envoyer le tout dans votre repertoire /js/ puis inclure le tout.

<script src="js/jquery-1.3.2.min.js" type="text/javascript" charset="utf-8"></script>
<script src="js/jquery.fontavailable-1.1.min.js" type="text/javascript" charset="utf-8"></script>

Passons maintenant au bout de code javascript à intégrer pour utiliser le tout.

	<script type="text/javascript">
	$(document).ready(function() {
	    if(!$.fontAvailable('Ma police exotique')) {
	      Cufon.replace('#article h3');
	    }
	});
	</script>

Conclusion

Passons maintenant au cheminement complet de cette technique :

1. Le visiteur arrive sur votre site, le dom se charge, la feuille de style css est appelé et essaie d’appliquer votre police exotique
2. Votre visiteur n’a pas la police exotique
   1. Il est sur un navigateur supportant @font-face, la police se télécharge.
   2. Il n’est pas sur un navigateur supportant @font-face, le document se charge, fontavailable teste la présence de la police et l’intègre
3. Votre visiteur a votre police exotique
   1. Rien ne se passe

Au final et pour revenir à mon introduction, certains d’entre-vous pourrons s’étonner de l’armada déployée pour l’occasion (qui n’est d’ailleurs pas plus importante que celle utilisée pour une intégration correcte de sIFR) mais le modèle peut être optimisé via fontavailable en ne limitant plus le test au changement de la police mais aussi au téléchargement de cufon-yui.js et votre fichier *.font.js.

Qu’est ce qu’un mémento ?

Un mémento est une sorte de brochure contenant l’essentiel des informations sur un sujet. En tant que travailleurs ou intéressés par le web, vous connaissez probablement les mémentos publiés aux éditions Eyrolles. Si ce n’est pas le cas, intéressez-vous y sérieusement, ces petits ouvrages sont tout simplement indispensable en cas de doute et/ou trou de mémoire.

Pourquoi un mémento microformat ?

J’avais commencé à écrire un mémento microformats il y a presque deux ans. L’idée était intéressante, la sémantique sur Internet est un sujet passionnant en ce qui me concerne. Les obligations professionnelles aidant, le projet était donc sagement resté dans un dossier sous la forme de brouillon. L’annonce de Google d’il y a maintenant deux semaines concernant le support des microformats et de RDFa dans le moteur de recherche ayant relancé la vague, c’était donc maintenant ou jamais.

Précisions

Avant de vous proposer le document en téléchargement, quelques précisions. Le mémento contiens les microformats les plus utilisés à l’instant T qu’ils soient définitifs ou encore au format brouillon. Le mémento ne contiens malgré tout pas le microformat XOXO, je vous invite à vous y intéresser mais il est très peu implémenté à l’heure actuelle car beaucoup de personnes n’y voient pas d’intérêt.

Au cours de la lecture, vous vous apercevrez également que certains microformats peuvent être intégrés à d’autres microformats. Le mémento détaille une bonne partie du microformat hCard mais ne fais pas la même chose pour hCalendar qui peut intégrer hCard ou hAtom qui peut intégrer hCalendar en plus de hCard. Si j’avais tout intégré, il n’y aurait quasiment que du code d’exemple et ce n’est pas forcément l’objectif d’un mémento.

Le mémento est donc estampillé révision 1.

Le Mémento Microformats par Alexandre BALMES est mis à disposition selon les termes de la licence Creative Commons Paternité – Pas d’Utilisation Commerciale – Pas de Modification 2.0 France.
Les autorisations au-delà du champ de cette licence peuvent être obtenues par mail.

La suite

N’hésitez pas à laisser vos commentaires pour demander des précisions qui pourraient également être intégrés au mémento. Souhaitez-vous plus d’exemples, de nouveaux microformats ou d’autres choses ? N’hésitez pas à le dire.

Téléchargement

Le mémento microformat est disponible au format PDF (4Mo)

Faire un don

Vous pouvez faire un don si vous avez aimé ce mémento. Petit indice, cela devrait me permettre de m’offrir PHP5 avancé

Tout le monde en a plus ou moins rêver, pouvoir créer un véritable annuaire sur Internet. Nombre de services s’y sont essayés et se sont affrontés par la même occasion avec plus ou moins de succès mais aucun n’est vraiment sortit du lot. Il faut dire que l’internaute confirmés ou non devant le panel d’offre peut être rapidement dépassé, ne reste donc que le technophile avec deux possibilités : choisir un service et l’utiliser au maximum ou les utiliser tous au tiers de leurs possibilités.

C’est la que le .tel arrive avec ses gros sabots, une extension avec un seul objectif, vous permettre de créer votre identité en ligne de manière formatée. De ce point de vue, le .tel est donc un véritable succès et représente enfin la solution à la fois acceptable en tant qu’annuaire et pourquoi pas le standard en devenir.

La ou le bas blesse, c’est sur la technique. Le .tel à plusieurs inconvénients, le premier et le plus évident est celui de l’hébergement puisque vous ne pourrez qu’acheter un .tel et utiliser la plateforme .tel pour l’héberger. L’avantage pour l’inconvénient du standard. Second point, la sécurité des données, l’ensemble des informations étant diffusées de la même manière et en clair, il est très facile de créer un parseur récupérant l’ensemble des informations disponibles sur les domaines .tel pour créer un véritable petit annuaire pour spammeur. Nous assistons donc à deux types de comportement vis à vis de l’extension, les premiers achètent un .tel et l’utilise en conscience plus ou moins évidentes des risques tandis que les seconds ne font qu’acheter le domaine, protection de l’identité numérique oblige.

Enfin et pour terminer avec les problèmes techniques, le .tel ne fait à mon sens que le travail à moitié. Un petit affichage du code source de la page vous permettra de mettre en avant un problème, le .tel n’utilise aucune des technologies de sémantisation de l’information. N’essayez donc pas de trouver de microformats ou encore de RDFa, il n’y en a tout simplement pas. Nous avons donc devant nous un outil sémantiquement formidable qui n’utilise aucun des moyens sémantiques en devenir – non je n’alimenterai pas le débat microformats vs RDFa.

Cette suite d’article, la première du devblog, va donc vous permettre de créer un équivalent du .tel version sémantique et personnalisable. Cette suite d’articles prendra donc la forme suivante et aura pour but de sortir une carte d’identité optimisé pour l’iPhone et le web – ou l’inverse c’est au choix – :

• La création d’une interface simple et adaptée aux mobiles.
• Comment faire une intégration sémantique à la fois en microformats et en RDFa afin de faciliter l’export d’informations.
• comment ajouter quelques effets javascript afin de créer une touche d’interactivité.

Et parce que je ne suis pas complètement contre le .tel, un lien vers le site Internet dans lequel vous retrouverez tous les renseignements pour vous en procurer votre .tel ainsi que tous les webservices ou applications développés pour en améliorer l’utilisation.