darkBlog

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

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 :

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'URL¹, 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é.

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é".