Bloc-notes de Tristan

Le but de PocMe est surtout pour moi de tester certaines solutions techniques.

Donc principalement Symfony 1.2 et Doctrine.

Symfony 1.2

PocMe est développé en PHP, basé sur le framework Symfony (branche 1.2). Du bonheur en barre Il permet de se concentrer sur l’essentiel, à savoir la partie métier. Toute la partie technique usuelle est laissée au framework.

La principale difficulté est que l’on a régulièrement tendance à implémenter quelquechose, sans savoir que symfony fournit déjà des outils pour cela. Donc pour être efficace avec symfony, il y a un ticket d’entrée minimum pour bien comprendre les notions de controleurs, de filtres, de slots, d’helpers, etc…

Donc passage par la case doc obligatoire, et là, c’est un régal: l’aide en ligne ainsi que le tutorial jobeet constituent l’une des principales forces de symfony, tant par la pédagogie que par l’ensemble des sujets couverts.

Seul petit bémol sur la doc de l’API, qui n’est pas propre à symfony d’ailleurs: j’aurais aimé que l’index des méthodes soit classé par ordre alphabétique, et que le résumé soit affiché à droite du nom de la méthode. Car en l’état, cet index est quasi inutilisable, je passais mon temps à faire des control-F. A moins d’utiliser la doc en ligne via un IDE.

Une autre source d’info extrêmement intéressante, c’est le code source de Symfonians, qui permet de découvrir des fonctionnalités dont on n’avait pas idée, des idées de solutions techniques et conception (je pense par exemple à la gestion des mails et de leurs templates, de l’implémentation de sfGuard, …), bref, j’ai énormément pompé sur ce site, merci NiKo

D’ailleurs, au sujet de sfGuard, il s’agit d’un plugins, certes, mais il ne faut pas s’imaginer qu’il suffit de l’activer pour avoir toute la gestion des utilisateurs. Tout ce qui concerne l’enregistrement, la confirmation, l’envoi de mot de passe, la gestion du profil, … reste à implémenter. Ce qui demande un effort considérable. Bien qu’une fois fait, j’imagine qu’il est facile de récupérer la majorité du code pour l’appliquer à une nouvelle appli.

Forms

Bien qu’il s’agisse d’un composant intégré à Symfony, il s’agit d’un package important, qui a fait couler pas mal d’encre.

Pour créer un formulaire, il faut avoir son bac ! Au début, on copie/colle un exemple de formulaire pour faire le notre, ou on le génère automatiquement, mais si on veut pousser le bouchon un peu plus loin, il faut retrousser ses manches et bien lire la doc (plusieurs chapitres dédiés). Le point positif est que la partie complexe réside dans l’objet formulaire et ses éventuels validateurs/formatteurs, et une fois cela fait, le code dans les actions et les templates reste simple.

Ma principale crainte en épluchant la documentation était de voir symfony tomber dans certains écueils de certains frameworks Java. Instruction trouvée sur le site du framework Hibernate:

Avoid over-design: aiming for too much abstraction and flexibility at an early stage is a great way to waste time that could be better spent solving actual problems that your actual users are facing. Do the simplest thing that can possibly work. Don’t try to solve problems that your users don’t care about. And it DOES NOT matter if your implementation is inelegant, at least initially. What matters is delivering useful functionality in a timely manner

Une fois les principes intégrés, un peu suspicieux, et après avoir un peu galéré pour les 2/3 premiers formulaires, je reconnais que le développement des suivants est de plus en plus rapide, et plutôt agréable.

Donc lorsqu’il s’agit de formulaires plutôt standard, la productivité est bonne. Lorsque les besoins deviennent plus spécifiques, la nouvelle mouture des formulaires n’est pas vraiment optimisée pour du développement bas niveau.

Exemple: j’ai pas mal sué avec la notion d’erreur globale … J’avais besoin d’avoir des templates un peu travaillés en fonction du type de l’erreur globale. Je n’ai pas réussi. Peut-etre y’a-t-il un bug, ou plus probablement, j’ai raté une ligne dans la doc. Toujours est-il que ce n’est pas évident.

Mais bon, ma petite appli n’a que des formulaires plutôt basiques, donc dans l’ensemble, j’ai plutôt apprécié le mécanisme.

Doctrine

Pour varier un peu les plaisirs, vu que je connaissais déjà Propel, cette fois-ci je suis parti sur Doctrine. Quelques points:

• La documentation est dense, et on ne trouve pas toujours l’information souhaitée dans le chapitre auquel on s’attend. Et certaines informations importantes sont noyées dans le reste de l’info (j’ai mis du temps à découvrir les magic finder !). Néanmoins, la doc a pas mal évolué entre temps. Et je viens à l’instant de découvrir un tutorial de Doctrine sur le site de symfony, voilà ce qui me manquait

• Les possibilités de schéma sont nettement plus puissantes sous Doctrine 1.1 que sous Propel 1.2.

• La contrepartie est que du coup, le schema.yml est plus complexe, il faut toujours sa cheat sheet à coté de soi (alors que pour Propel c’etait particulièrement simple).

• Le requêtage est très proche du SQL. Avec Propel, on en était très loin, et dès que l’on voulait faire des requêtes complexes (alliant plusieurs jointures, clauses et/ou, …), il vallait mieux passer en mode requête SQL (sinon le code devenait difficilement maintenable).

• Performances ? Aucune idée

En tout cas, parfaitement intégré à Symfony.

Fonctions PocMe

Concernant l’appli PocMe, qq points notables:

S’enregistrer: sur tous les sites que je connais, pour s’enregistrer, il faut saisir 2 fois le mot de passe. Et je trouve ça irritant ! Ca devient tellement une habitude qu’au final, je fais un copier/coller du 1er password dans le 2nd, ce qui enlève tout interet à la vérification, je sais Je me doute bien que le but est d’avertir l’internaute s’il a fait une faute de frappe. Et alors ? S’il s’est trompé, il suffit qu’il fasse la demande ‘mot de passe perdu’, et voilà ! Honnêtement, dans combien de cas on se plante dans la saisie d’un mot de passe ? Disons qu’on est vraiment manchot, on se trompe une fois sur 5. Et du coup, pour 4 inscriptions sur 5, ce champs supplémentaire n’a aucun intérêt si ce n’est alourdir le formulaire d’inscription. Bref, j’avais envie de changer un peu cette habitude (oui, je sais, je suis un énorme rebelle )

Dates: c’est l’aspect le plus complexe de l’application. Car gérer des dates fixes, pas de pb, mais gérer des dates répétées (tous les mois par ex), c’est une horreur. Donc le gros du temps passé sur l’appli concerne la gestion de ces date.

Mails: j’ai tout simplement repris le principe que j’ai vu dans Symfonians, à savoir sfSwiftPlugin, allié à un module dédié pour les templates, et se connectant à un serveur SMTP de Google Apps. Seul petit hic: les performances pour l’envoi de mails, pas très rapide, il faudra que je voie si je peux améliorer cela.

Tests automatiques: comme tout le monde, j’adore ce principe, j’avais commencé à les mettre en place au début en utilisant la lib de symfony, mais ça prend du temps à mettre en place, j’ai fini par abandonner

Scripts automatiques: lancés via cron évidemment, j’ai un peu galéré car j’ai réalisé tardivement que mon script devait appeler le controlleur (notamment à cause des templates de mails). Je ne souhaitais pas passer par Apache (à cause des éventuels timeout). Je suis donc passé par le sfConsoleController au lieu de l’habituel sfWebController. Puis j’ai dû bidouiller un poil pour qu’il soit exécuté avec le rôle admin.

Voilà, au final, je me suis plutôt bien amusé, et ce n’est pas fini

Tristan Développement doctrine, php, symfony