darkBlog

mercredi 25 octobre 2006

Quick and dirty : Live HTTP Headers 0.12 avec Firefox 2.0

Téléchargez la dernière version de Live HTTP Headers (à ce jour la 0.12, incompatible avec Firefox 2.0), dézippez l'archive, éditez le fichier install.rdf, remplacez la ligne :

<em:maxVersion>1.5+</em:maxVersion>

par :

<em:maxVersion>2.0.0.*</em:maxVersion>

Rezippez l'archive (en conservant l'extension .xpi bien entendu), glissez le nouveau fichier dans Firefox , et le tour est joué.

jeudi 19 octobre 2006

Attention aux recherches avec les éditeurs de contenu WYSIWYG

S'il est attrayant d'intégrer un éditeur de contenu WYSIWYG dans ses applications web, un point sur lequel il convient de faire attention est la recherche. En effet, ce type d'éditeur produit du code HTML que l'on enregistre typiquement dans une base de données. Le problème est qu'une recherche sur le contenu saisi par ce biais peut être largement déficiente, et ce pour deux raisons principales :

  • Parce qu'on peut ne pas retrouver les informations recherchées à cause de caractères spéciaux transformés en entités HTML, et
  • Plus grave, parce qu'on peut retrouver des informations liées à la présentation : couleurs (red, blue, etc), polices ("times new roman", etc), ou même plus simplement des balises HTML (strong, etc).

Ces problèmes doivent être traités séparément. Le premier peut se résoudre simplement, soit en empêchant la transformation des caractères spéciaux en entités HTML coté éditeur (pour TinyMCE par exemple, spécifier le paramètre entity_encoding : "raw"), soit en refaisant la transformation inverse coté serveur.

Pour le second point, c'est plus délicat. On peut commencer par retirer certains contrôles de l'éditeur comme celui du choix de la police ou de la couleur, mais ça n'empêchera pas l'utilisateur de faire un copier/coller brutal d'un fichier Word, pas plus que ça ne règlera le problème des balises HTML (mais au moins votre application ne ressemblera pas à un skyblog, c'est toujours ça de gagné).

Une solution acceptable est de stocker dans un champ à part le code généré par l'éditeur mais dénué de toute code HTML. Une telle opération de nettoyage se fait très facilement avec PHP (voir la fonction strip_tags), plus difficilement avec Domino (voir un peu plus bas pour une implémentation possible). Le texte résultant de cette opération n'aura plus forcément de sens, mais constituera une liste de phrases et de mots clés pertinents sur laquelle on pourra baser une recherche avec confiance. Je dis acceptable et non pleinement satisfaisante car une partie des informations peut être perdue lors du nettoyage : les URL des liens par exemple (il n'en restera plus que les libellés).

Voilà quelques conseils issus de mon expérience mes déboires en la matière. Pour l'implémentation avec Domino, ça peut se faire en quelques lignes à l'aide de l'expression rationnelle qui va bien (ici windows uniquement, mais une implémentation multi-plateforme [et plus lente] est possible avec Java) :

doc.ContentWithoutHTML = Join(Fulltrim(Split(stripHTML(doc.Content(0)), " ")))

Function stripHTML(sTexteHTML As String) As String
    Dim re As New RegExp
    re.Global = True
    stripHTML = re.Replaces(sTexteHTML, "(<[^>]+>)", " ")
End Function

IE7 et Websphere Portal 5.1 sont dans un bateau. Qui tombe à l'eau ? Les iframes !

A moins de ne pas avoir allumé votre ordinateur de la journée, il y a assez peu de chances pour que vous soyez passé à coté de la sortie d'IE7. Cet après-midi, je l'ai installé dans une machine virtuelle afin de tester la compatibilité des applications web de mon client. En allant voir le portail de l'entreprise basé sur IBM Websphere Portal 5.1, j'ai été très surpris de tomber sur le message suivant :

The portlet cannot be displayed because your browser does not support iframes
Un portlet de clipping avec IE7

J'ai d'abord cru à une blague de Microsoft, du genre désactivation des iframes dans la configuration par défaut pour une vaseuse excuse de sécurité (ils l'ont bien fait du jour au lendemain pour les identifiants dans l'URL1, hein). Après un petit tour infructueux du coté des options d'IE7, je suis finalement allé jeter un coup d'oeil à la configuration du portail. Et c'était bien là que la solution résidait.

En effet, il s'avère que WPS rend les pages différemments selon les capacités des agents utilisateurs, et que forcément, IE7 n'étant pas déclaré dedans, c'est le mode le plus dégradé qui a été proposé. Une louable intention, mais qui nous a fait une belle frayeur quand même (surtout à mon client, qui s'est décomposé à une vitesse que je n'aurais pas cru biologiquement possible). Bref, une petite modification de la regexp de détection des agents utilisateur et le problème était réglé.

Ecran de configuration des agents utilisateur
Avec une règle prioritaire on matche désormais toutes
les versions d'IE. Comme ça on est prêt pour IE 8.

1 : Ce qui empêche au passage d'utiliser le credential vault du portail pour l'authentification BASIC et nous oblige à implémenter tout un tas de bidouilles pour fournir un service équivalent. Vous n'avez pas idée de l'énergie inutilement déployée comme de l'argent gaspillé à cause de cette "mise à jour de sécurité".

mardi 10 octobre 2006

Problème de version de l'API MySQL avec les paquets PHP5 dotdeb ?

En essayant de configurer (tant bien que mal) la Debian Sarge de ma Dédibox (après être passé par l'Ubuntu-Dedibox, puis l'Ubuntu-Server 6.06, puis la Gentoo 2006.0, pour finalement revenir vers Debian), je me suis aperçu d'une chose curieuse avec les paquets PHP5 dotdeb : la version de l'API du client MySQL (Client API version) est la 4.1.15, alors que mon serveur MySQL est un 5.0.24 (paquet dotdeb également).

A y regarder de plus près, on s'aperçoit que la librairie libmysqlclient14 (4.1.15) est déclarée comme dépendance des paquets php5-mysql et php5-mysqli :

darkbox:~# apt-cache show php5-mysqli
Package: php5-mysqli
Version: 5.1.6-0.dotdeb.2
Depends: libc6 (>= 2.3.2.ds1-21), libmysqlclient14, zlib1g (>= 1:1.2.1), debconf (>= 0.5) | debconf-2.0, phpapi-20041225, php5-common (>= 5.1.6-0.dotdeb.2)

Plus curieux encore, si je tente de la déinstaller, le système m'indique de nouvelles dépendances, et pas des moindres, comme mysql-client-5.0 ou encore mysql-server-5.0 :

darkbox:~# apt-get remove libmysqlclient14
Les paquets suivants seront ENLEVÉS :
libdbd-mysql-perl libmysqlclient14 mysql-client-5.0 mysql-server-5.0 php5-mysql php5-mysqli php5-pdo-mysql
0 mis à jour, 0 nouvellement installés, 7 à enlever et 0 non mis à jour.

En l'état, j'imagine que le serveur pourrait fonctionner tout à fait normalement, vu le nombre manifeste de serveurs qui tournent sous cette configuration . Pourtant, pour peu que l'on recherche sur Google, on peut trouver quelques témoignages de personnes ayant rencontré des problèmes d'insertion ou de mise à jour de tables dans cette configuration. On peut également voir chez MySQL dans la F.A.Q de l'extension PHP qu'il est déconseillé d'avoir une API cliente de version inférieure à celle du serveur.

J'avoue que je ne sais pas trop quoi faire. Partir à la recherche d'autres repositories (j'ai cru en voir au détour de quelques forums...) ? M'orienter vers une autre distribution (à tout hasard, revenir vers Gentoo) ? Ou bien refourguer ma dédibox et prendre un mutualisé, parce que ça va bientôt un mois que cette histoire traîne et que je commence sérieusement à en avoir marre ?

dimanche 1 octobre 2006

Fil RSS réparé

Le fil RSS du blog était manifestement cassé depuis mon billet sur la biège belge à Paris, soit depuis un bon paquet de temps. Ceci était dû au code javascript pour l'intégration de Google Maps qui contenait un bloc CDATA et dont la fin fermait en réalité le bloc principal <content:encoded><![CDATA[ de l'item. Pour régler le problème, j'ai collé le code dans une ressource javascript externe, mais je me demande bien comment on peut gérer ce type de problématique (blocs CDATA imbriqués ?).

Merci à Tetert de me l'avoir signalé.