Not Just another technical weblog…

J’utilise Twitter depuis maintenant quelques temps et j’ai vu à travers ce service l’utilité d’accéder à un outil de simplification d’URL.
Lorsque l’on écrit des commentaires, il est vraiment intéressant de ne pas occuper l’espace avec des liens trop longs mais plutôt avec une explication concrète autour…

Bit.ly est beaucoup utilisé sur Twitter, j’ai donc cherché les différentes possibilité offertes par ce WebService. A travers un compte utilisateur gratuit créé sur le site, vous avez ensuite accès à une API (Interface de Programmation) de type REST (Representational State Transfer).
Le projet associé à ce service est hébergé sur Google Code et disponible à l’URL: http://code.google.com/p/bitly-api/

Ce type d’architecture est très répandu sur le web et utilisé pour diverses applications (Recherche, Récupération d’informations comme la météo, …). Elle permet d’apporter des services supplémentaires sur un site qui sont de plus en plus demandés.

Pour Bit.ly le fonctionnement est le suivant:

• Pour chaque requête, une connexion à votre compte utilisateur gratuit est requis avec login et Api Key
• Différents formats de communications sont possibles (JSon, XML)
• Des librairies implémentant la communication avec ce service sont disponibles dans plusieurs languages (PHP, JavaScript, ActionScript, …)
• Les 5 commandes possibles sont décrites sur la page du projet sur Google Code

Pour chaque lien créé à travers ce service, des statistiques de clic sont générées ce qui permet d’assurer un suivi assez précis de ses liens.

Si vous devez implémenter un système de commentaire sur votre site, j’espère que cette présentation vous aidera à l’améliorer. D’autres services du même type existe comme Goo.gl mais l’utilisation très répandu et la simplicité m’ont fait choisir Bit.ly.

J’ai eu souvent l’occasion d’utiliser XSL pour gérer des templates d’affichages.
En effet j’ai eu beaucoup l’habitude de travailler avec des contenus XML pour leur structure simple à exploiter. Ce type de contenu permet, à mon sens, une séparation plus simple entre traitement et affichage qu’avec une base de données.

Cependant les feuilles de style XSL sont assez limitées dans les traitements car même si elles permettent des boucles et des calculs simples, toutes les informations utiles doivent être stockées dans le XML pour être exploitées directement par le XSL.
Cette exhaustivité d’information est assez rare et plus particulièrement dans l’affichage des médias. XSL ne permet pas, contrairement à PHP, de tester l’existence d’un fichier, de redimensionner une image ou de lire des meta-données associées à un fichier.

Pour réaliser ces traitements plus avancés, le processeur XSLT associé à PHP (XSLTProcessor inclut dans le module php_xsl) permet l’appel de fonction PHP à travers XSL.

Pour cela il faut créer une feuille de style XSL en ajoutant l’espace de nom XML PHP dans l’en-tête:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:php="http://php.net/xsl" >
...
</xsl:stylesheet >

Pour activer l’utilisation de ce nouvel espace de nom, il faut lors de la construction de l’objet XSLTProcessor appelé l’instruction suivante:

$oXSL = new XSLTProcessor( DOMDocument::load( "chemin-vers-mon-fichier" ) );
$oXSL->registerPHPFunctions();

Afin d’être utilisées dans la feuille XSL, les fonctions PHP doivent être déclarées en amont de la construction de l’objet XSLTProcessor. Voici un exemple d’appel à une fonction écrite en procédural:

function AfficherTexte( $sText )
{
   return $sText;
}

...
<xsl:value-of select="php:function('AfficherTexte', $myText)" />

Voici un autre exemple d’utilisation avec une fonction statique:

class Text
{
   public static function Afficher( $sText )
   {
      return $sText;
   }
}

...
<xsl:value-of select="php:function('Text::Afficher', $myText)" />

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…