Comme toute API qui se respecte, celle de Flex 2 réserve son lot de bizarreries. Cette semaine, j’ai eu besoin d’afficher un label cliquable. Et pour bien montrer à mes utilisateurs Web que ce label est cliquable, je voulais que le curseur en forme de main s’affiche lorsque la souris passe au dessus de ce label.
C’est le genre de truc qu’on fait des milliers de fois sans se poser de question en HTML:
<span style= »cursor:hand;cursor:pointer;text-decoration:underline » onclick= »alert(‘Facile…’) »>Cliquer ici</span>
En Flex, l’équivalent se nomme useHandCursor. On s’attend donc à ce que le code suivant fonctionne:
<mx:Label text= »Cliquer ici » useHandCursor= »true »/>
Que nenni ! Rien nada. Pas de curseur en forme de main, rien. De deux choses l’une: Ou bien c’est un bug, mais dans ce cas comment se fait-il que personne n’ai trouvé ce bug aussi évident depuis la sortie de Flex 2 en 2006?… ou bien c’est un de ces cas où le design de l’API laisse à desirer et où changer la valeur de la propriété ne suffit pas. Encore faut-il trouver ce qui manque.
Et là, les gars de chez Adobe-Macromedia m’ont épaté:
Il faut modifier non pas UNE propriété…
non pas DEUX….
mais… TROIS !!!
Et, oui, c’est carrément trois propriétés qu’il faut changer pour voir apparaitre ce fameux curseur en forme de main.
Il faut donc dire à notre label, de montrer son curseur (useHandCursor=true), de se comporter comme un bouton (buttonMode=true) et enfin de ne pas déléguer les évènements de la souris à ses enfants (mouseChildren=false). On a connu plus intuitif !
Pour résumer voici le code MXML qu’il faut écrire pour voir notre curseur fétiche.
<mx:Label text= »Mais tu vas cliquer ici, oui ! » useHandCursor= »true » buttonMode= »true » mouseChildren= »false » />
Selon Brad Abrams, un des pères de l’API de .NET, une API bien conçue est une API qui fait tomber le développeur dans la fosse du succès (The Pit of Success). Tel un marcheur qui essayerait de passer d’une vallée à une autre, et qui passera naturellement par le col plutôt que d’escalader le pic, une API bien conçue guide les développeurs dans la bonne direction, et leur rend la tache compliquées quand ils ne sont pas sur le bon chemin.
Dans le cas de useHandCursor, par exemple, je pense qu’il aurait été préférable de surcharger la propriété pour mettre à jour les 2 autres propriétés, ou au moins de l’indiquer clairement dans la documentation.
12/03/2008: Remplacé showHandCursor par useHandCursor.