Bloc-notes de Darathor

Auto-complétion du code avec PDT

PDT est un IDE pour PHP basé sur Eclipse relativement performant. Notamment il permet l’auto-complétion de code, ce qu’on n’a que rarement avec des éditeurs plus légers.

Sous certaines conditions (notamment avec le plugin SVN), l’auto-complétion n’est pas activée par défaut. Il y a peut-être moyen de le régler dans le labyrinthe qui sert de système d’options à Eclipse mais sinon, un moyen simple reste d’ajouter la ligne suivante dans la section natures du fichier .project du projet :

Flux RSS et format de date

Pour formater une date en vue de générer un flux RSS, il y a plusieurs méthodes :

1. chercher le détail du format sur le net et l’appliquer… c’est possible mais risque d’erreur.
2. utiliser le format ‘r’ qui renvoie le bon format.
3. utiliser la constante DateTime::RFC822… sauf que là le flux ne sera pas forcément valide et qu’il y aura potentiellement des problèmes avec certains agrégateurs.

Préférez donc la seconde solution, celle-là en principe elle marche (et en bonus c’est la plus compacte, que demander de plus ?).

Méthodes privées en PHP 5.1.6

Le principe d’une méthode privée c’est d’être interne à la classe et aucunement visible ou surchargeable depuis une classe qui l’étend (contrairement à une méthode protégée). Cependant dans certaines versions de PHP, dont la 5.1.6 (je ne sais pas quand exactement il a été corrigé mais il n’est plus présent dans les dernières 5.2.x), permet de surcharger les méthodes privées d’une classe… Ça peut arriver involontairement et ne prête pas à conséquence, sauf quand par la suite vous tentez d’exécuter votre script sur une version corrigée de PHP et là c’est pas évident de comprendre pourquoi tout d’un coup on ne passe plus dans la surcharge !

L’angoisse de la page blanche #2

J’évoquais ici le fait qu’on risquait une page blanche sans autre forme de procès en déclarant deux fois une même méthode dans une même classe et en voici un autre : déclarer comme abstraite une méthode d’une interface.

C’est peut être une déformation due au fait qu’on me l’a présenté comme ça lors de mes premiers cours de programmation objet Java mais pour moi une interface c’est pousser à l’extrême le concept de la classe abstraite : toutes les méthodes sont abstraites (et on n’a pas de champs). En Java, il me semble bien me souvenir que dans le cas d’une interface, le mot-clé abstract sur une méthode est facultatif (vu que de toutes façons toutes les méthodes d’une interface le sont). Eh bien en PHP il n’est pas facultatif mais interdit. Sinon, page blanche (du moins sous certaines versions/configurations) et bon courage pour retrouver l’erreur \o/

Préambule…

Hier, j’avais à parcourir un tableau d’objets (pouvant avoir potentiellement des centaines voire exceptionnellement milliers d’entrée) pour rechercher si l’identifiant de l’un d’eux se trouvait dans un second tableau. J’avais commencé par utiliser pour ça la fonction in_array() à chaque itération pour voir si l’identifiant de l’objet était présent ou non dans le second tableau.

En voyant cela, un collègue m’a fait remarquer que ce serait peut-être plus performant de construire un tableau dont les clés sont les valeurs du second tableau (via array_flip()) pour pouvoir utiliser isset() au lieu de in_array() et voici les résultats obtenus :

Structure du bench

Le bench consiste à rechercher 100 000 fois la même valeur dans le tableau array('11345', '7437', '7329', '45494', '7894311', 'sdfsdg', 'qsqsdcirt', 'd787 sdfs df'), avec trois méthodes différentes :

• in_array()
• array_flip() suivi de isset()
• array_flip() suivi de array_key_exists()

Le test est effectué avec deux valeurs différentes : d’abord avec la première valeur du tableau (cas théoriquement le plus favorable puisqu’on arrête la recherche une fois la valeur trouvée) puis avec une valeur qui n’est pas dans le tableau (cas théoriquement le plus défavorable puisqu’on est obligé de parcourir tout le tableau). Le résultat en conditions réelles sera donc compris dans cette fourchette.

Cas in_array()

Code exécuté :

Cas favorable ($value = '11345') : ~0.33 secondes
Cas défavorable ($value = 'uottuyi') : ~0.52 secondes

Cas isset()

Code exécuté :

Cas favorable ($value = '11345') : ~0.12 secondes
Cas défavorable ($value = 'uottuyi') : ~0.09 secondes

Cas array_key_exists()

Code exécuté :

Cas favorable ($value = '11345') : ~0.27secondes
Cas défavorable ($value = 'uottuyi') : ~0.24 secondes

Et pour de plus petites quantités ?

Les grands volumes c’est bien mais qu’est-ce que ça donne quand on a peu d’itérations ?

Un test à 5 itérations au lieu de 100 000 donne environ le même résultat pour les trois méthodes : avec ~6E-05 secondes pour les méthodes 1 et 3 et ~5E-05 pour la méthode 2.

Tandis qu’un test sur une unique itération donne la première méthode gagnante avec ~4E-05 secondes contre ~5E-05 pour les deux autres (à ce niveau c’est le array_flip pour transformer les valeurs en clés qui coute cher).

Conclusion

À moins d’avoir toujours très peu d’itérations (moins de 5), la méthode passant par array_flip() puis isset() est d’assez loin la meilleure (environ quatre fois plus rapide sur des grands nombres et pas plus lente sur des petits).

En passant, on remarque aussi qu’avec cette méthode, rechercher une valeur qui n’existe pas dans le tableau est plus rapide que de rechercher la première valeur du tableau, même si je ne vois pas forcément trop pourquoi

Une deuxième série de petits trucs sur PHP…

Page blanche

Plus j’utilise PHP, plus je me rends compte qu’il y a quand même des trucs bien foireux dedans… Notamment ceci : lorsqu’une classe contient deux définitions de la même méthode (du moins dans certains cas, j’ai pas trop approfondi pour voir si c’est vraiment systématique), on n’obtient pas d’exception, ni même la traditionnelle “fatal error” non-catchable et sans trace, mais bel et bien une page blanche sans aucune explication \o/ J’imagine que derrière PHP doit mourir lamentablement sur un “Segmentation fault”… Bref, quand vous obtenez une page blanche, pensez à vérifier si vous n’avez pas raté un copier/coller quelque part…

Duplication de tableaux

Après avoir tenté en vain de dupliquer un tableau avec le mot-clé clone (qui retourne null), j’ai cherché un peu et je suis tombé sur cet article. Donc apparemment une simple affectation suffit à dupliquer un tableau (ce qui explique au passage certaines choses concernant la quantité astronomique de mémoire qu’arrive à bouffer PHP dans certains cas) ! Comme quoi même en utilisant un langage pendant des années, on peut passer à côté de certains trucs de base…

L’instruction continue

Je parlais il y a quelque temps de l’instruction break qui admet un paramètre permettant de sortir de plusieurs boucles imbriquées d’un coup, eh bien l’instruction continue se comporte de la même façon.

Je n’avais pas insisté dessus à l’époque (parce que dans le cas du break, c’est évident) mais dans les deux cas, un switch est considéré comme une boucle. Donc si vous êtes dans un switch contenu dans une boucle et que vous voulez passer à la prochaine itération de la boucle il faut appeler un continue 2;.

Pour plus de détails sur l’instruction continue, rendez-vous sur le manuel officiel de PHP.

Vu qu’on m’a posé certaines questions là dessus cette semaine, ça va faire le sujet de l’article d’aujourd’hui.

Ajouter une seconde zone de widgets

Depuis la version 2 (il me semble) de WordPress, si le thème est bien fait, on peut depuis le panneau d’administration ajouter des widgets dans certaines zones bien définies. Dans le thème par défaut, il y a une zone unique pouvant accueillir des widgets, qui se trouve dans la barre latérale. Mais on peut vouloir en ajouter d’autres.

Pour ajouter une nouvelle zone, il faut effectuer deux modifications dans le code du thème :

1. premièrement, il faut “enregistrer” une nouvelle zone pour que celle-ci soit disponible dans le menu de sélection des zones. Pour cela il faut en général se rendre dans le fichier functions.php du thème et rechercher où est appelée la fonction register_sidebar (dans le thème par défaut, c’est tout en haut du fichier) et l’appeler une fois de plus pour enregistrer une nouvelle zone.

   Cette fonction peut optionnellement prendre en argument un tableau de paramètres permettant de personnaliser le code HTML qui enrobera la liste de widgets. Dans la plupart des cas on n’en a pas besoin mais au cas où c’est bon de savoir que c’est possible, notamment pour éventuellement spécifier une classe particulière à l’une ou l’autre zone en vu d’appliquer des styles différenciés.

   Une fois cela fait, la nouvelle zone est disponible dans le menu de sélection des zones du panneau d’administration (cf la capture d’écran ci-dessus).

2. dans un deuxième temps, il faut inclure cette zone dans le rendu de la page à un endroit ou un autre (sinon, forcément, ça sert pas à grand chose). Pour cela il suffit d’intégrer le code suivant dans l’un des fichiers de template :
   

   Code

   <?php dynamic_sidebar(n); ?>
   en prenant garde de bien remplacer le paramètre “n” par un entier représentant le numéro de la zone que vous voulez afficher.

   Par exemple, si vous venez d’ajouter une zone et qu’il y en avait une seule avant, la nouvelle aura fort logiquement le numéro 2 et le code à insérer sera le suivant :

   Code

   <?php dynamic_sidebar(2); ?>

N’afficher certaines choses que sur la page d’accueil

Afin de ne pas trop surcharger les pages on peut ne vouloir afficher certaines informations et liens que sur la page d’accueil. Par exemple sur ce site, les encarts “Mes autres sites”, “News du serveur” et “Divers” ne s’affichent que sur la page d’accueil (et les pages de contenu fixe).

Pour restreindre l’affichage d’une portion de code d’un fichier de template, c’est très simple :

WordPress propose quelques fonctions PHP qui testent dans quel type de page on se trouve et qui peuvent servir à composer la condition (qui remplacera la portion “[CONDITION]” du code ci-dessus). Ces fonctions sont définies dans le fichier wp-includes/query.php et comprennent notamment :

• is_home() disant si l’on se trouve sur la page d’accueil.
• is_page() disant si l’on se trouve sur une page de contenu fixe.
• is_search() disant si l’on est dans la page de recherche.
• is_404() disant si l’on se trouve sur la page d’erreur 404.
• etc.

Pour composer la condition, il suffit d’appeler une ou plusieurs de ces fonctions séparées par une double barre verticale (||) qui représente un “ou” en PHP.

Par exemple pour ajouter une zone de widgets qui ne sera affichée que sur la page d’accueil et les page de contenu fixe, on utilisera le code suivant :

Et ça marche que pour la barre latérale ?

Bien entendu ces deux “astuces” sont valable aussi bien pour la barre latérale que pour n’importe quelle autre partie de votre site. Mais c’est dans la barre latérale que c’est le plus souvent utilisé.

Quelques petits trucs que je n’ai appris que récemment. Peut-être étais-je le seul à les ignorer… ou peut-être pas, donc dans le doute…

Sortir de plusieurs boucles à la fois

Classiquement l’instruction break; s’utilise telle quelle pour sortir de la boucle ou du switch courant. Cependant en PHP (et sans doutes dans d’autres langages également), on peut lui adjoindre un paramètre entier permettant de sortir de plusieurs boucles à la fois. Ceci est à utiliser avec parcimonie car ce n’est pas forcément des plus lisible mais ça peut aider à accélérer une recherche dans un tableau multi-entrées par exemple :

Paramètre de la fonction die

C’est plus une instruction qu’une fonction mais bon, passons. Elle peut prendre en argument un entier ou une chaine de caractère mais cet argument n’est affiché à l’écran que s’il s’agit d’une chaine. Ça n’a l’air de rien mais c’est bon à savoir…

DOM ou SimpleXML ?

SimpleXML c’est bien gentil et comme son nom l’indique, c’est «simple» (du moins dans son interface qui compte très peu de méthodes), mais à l’usage c’est quand même des plus limités. Et c’est plutôt chiant à utiliser parce qu’il faut caster pas mal de choses pour obtenir des chaines de caractère au lieux de nœuds XML (sans compter le bug dont je parlais il y a quelques temps). D’autant qu’il existe une alternative…

En effet, j’en étais resté à PHP4 où l’API DOM se cantonnait l’extension DOM XML non-incluse par défaut, ce qui n’était pas bien pratique… Mais en PHP5, elle a été remplacée par une nouvelle implémentation incluse en natif dans PHP sous le nom de DOM. Bref, en ce qui me concerne, SimpleXML va direct à la poubelle et je n’utilise plus que DOM, avec l’avantage supplémentaire d’être similaires aux bibliothèques DOM présentes dans d’autres langages tels que Javascript, puisque DOM est un standard, ce qui raccourcit d’autant l’apprentissage.