Archive for novembre 2009

Pourquoi ne pas utiliser PHP comme moteur de Template

Pour répondre à cette question, je vais m’appuyer sur un article publié par Fabien Potencier sur le sujet: Templating Engines in PHP. Fabien Potencier est un membre très actif de la communauté symfony, il est aussi le PDG de la société Sensio à l’origine du projet.

Il décrit dans cette article les différentes raisons qui l’ont fait changer d’avis sur les templates PHP. En effet, aujourd’hui, j’utilise souvent PHP pour construire mon HTML rapidement sous la forme de templates simpliste (passage de variable par fonction extract puis utilisation dans un fichier HTML template).

Pour un développeur cette méthode fonctionne à merveille mais n’est pas très souple. Dès que l’on doit rajouter une nouvelle information, il faut repasser dans le HTML, le PHP, parfois le JavaScript pour réorganiser le tout… Rapide me direz-vous? Pas si on remet le template à sa place.

En effet le Template sert normalement à gérer l’affichage des données. En modèle MVC, il est utilisé dans les vues pour mettre en forme les données transmises par le contrôleur. Pour cette raison, un Web Designer peut conscient des technologies PHP doit pouvoir s’approprier facilement les Templates pour les modifier. Il ne devrait pas se soucier des données, de la forme, l’encodage, le découpage, la cesure et tout ce qui s’en suit…

Par rapport à se constat, PHP n’est pas un moteur de Template adapté pour être utilisé dans une équipe de création structurée et multi-compétences. Pour cela des moteurs de Template simples (attention à utiliser pas à réaliser) comme celui utilisé dans le FrameWork Django. Il en éxiste d’autres mais je trouve celui-ci vraiment souple et puissant par rapport à d’autres.

Il utilise une syntaxe et un interpréteur développer spécifiquement pour répondre à la besoin de la création de Templates. Il est possible d’utiliser des variables, de faire des boucles, des conditions booléennes de l’inclusion de fichier, des filtres sur les données (couper quand trop long, mise en minuscules/majscules…). La syntaxe très simple peut être utilisée par n’importe quel public technique non développeur (Monteur, Web Designer, …).

Un éventail des possibilités de ce moteur de template se trouve sur le site: http://www.biologeek.com/django,traduction,web-frameworks/le-langage-de-template-django-pour-les-auteurs-de-templates/

La documentation est accessible directement sur le site du projet Django: http://docs.djangoproject.com/en/dev/ref/templates/builtins/

Outil puissant de génération de HTML et CSS par Zen Coding

Je viens de tomber sur un article intéressant du Smashing Magazine. Cet article présente un plugin de Zen Coding pour le HTML / CSS proposé initialement par Vadim Makeev. Il s’interface avec des IDE connus sous différentes plateformes, d’Aptana Studio à Espresso en passant par GEdit ou TextMate et permet de combiner snippets et commande intelligentes.

Ce logiciel / plugin permet d’écrire des commandes permettant de générer du HTML. Vous pouvez voir un exemple sur l’IDE Espresso sur Mac dans la vidéo ci-dessous:

Etant plutôt un développeur Système, je ne suis pas très fan du montage HTML. Ce qui m’interesse particulièrement dans cette technologie est la rapidité de codage d’une page web complexe.

Vous trouverez l’article complet à l’adresse : http://www.smashingmagazine.com/2009/11/21/zen-coding-a-new-way-to-write-html-code/

DatePicker et Calendrier Eightysix

Eightysix est un nouveau calendrier JavaScript basé sur Mootools 1.2.4 (dernière release le 11 octobre 2009). Il n’utilise pas du tout de PHP et très peu d’Ajax pour garantir une rapidité d’execution exemplaire.

Il est très paramétrable et facile à intégrer :
- Format de date avancé (le même que PHP)
- Internationalisation directement gérée dans les options
- Et une liste d’options assez longue

Plusieurs exemples d’implémentation sont disponibles sur le site et permettent de voir l’étendue des possibilités.

Par rapport aux autres calendriers JavaScript que j’ai été amené à utiliser, EightySix me parait plus léger (9,5Ko compressé) et utilise une version très récente de Mootools ce qui permet de ne pas être bloqué par cette librairie.

Cette bibliothèque a été développée sous Creative Commons Attribution- NonCommercial 3.0 License et est disponible au téléchargement ici.

Gestion des logs d’erreurs dans Apache

Normalement ce post ne devrait pas avoir lieu d’exister vu que le développement, quand il est bien fait ne génère pas d’erreur et tout se passe toujours bien…

Bon redescendons sur terre, les applications web déclenchent des erreurs, qu’Apache récupère dans son fichier de log. Dans certains cas ces fichiers deviennent très gros après un certains temps (ou très rapidement en fonction du développement) ce qui pose quelques problèmes côté serveur comme des lenteurs d’écriture sur disque.

Pour remédier à ce genre de problème ou simplement améliorer les pratiques, il est intéressant de bien savoir gérer les logs Apache. J’ai trouvé un article décrivant brièvement les différentes posssibilité de gestion des logs :
- Personnalisation de la forme
- Niveau du log (Warn, Info, …)
- Emplacement et gestion des fichiers

Vous trouverez cet article rédigé par Web Reference ici.

Ce qu’il faut faire pour migrer une application PHP 5.2 vers 5.3

Aujourd’hui bon nombre d’applications / sites web sont développés sur PHP 5.2.x. Cette version est extrêmement répandu chez les hébergeurs comme chez les développeurs.

La version PHP 5.3 qui est sortie début juillet 2009 a commencé à être mise en place chez les hébergeurs (OVH par exemple) ce qui va favoriser la démocratisation.

Elle apporte son lot de nouveautés comme:
- La gestion des espaces de noms (plus de nom de classe à rallonge comme dans le framework Zend)
- De nouvelles extensions ( ext/phar, ext/intl, ext/fileinfo… )
- Les étiquettes ( goto )
- Le collecteur de références circulaires
- Le support de Late Static Bindings

Pour ma part, rien que la première nouveautés me demande d’y passer en plus des grands gains de performances entre 20 et 30%. J’ai donc cherché les différents problèmes que je pourrais rencontrés en réalisant cette migration.

Je suis bien sur tombé sur le manuel de migration diffusé par php.net mais j’ai aussi trouvé un article de Maxime Varinard, contributeur chez Developpez.com. Cet article décrit rapidement les principales fonctions à ne plus utiliser et il permet de « faciliter la migration ». Il se trouve ici