Nous connaissons tous ce bouton par coeur, il est partout, il est tout le temps, il est « gris » (;-)) ;  mais finalement, a t-il encore lieu d’être aussi présent dans nos applications qu’elles soient standalone ou web .

Prenons, l’exemple simple, du bouton OK pour valider un formulaire : le fameux « submit ».

Finalement, coté code, aucun problème pour ne pas en mettre au profit d’appuyer sur touche entrée

Pourquoi donc le garder à toutes les sauces.

En fait, ce billet restera de manière volontaire ouvert à vos commentaires sur ce sujet. Je me suis ici contenté de vous poser cette question et attend avec impatience vos remarques

Je voulais toutefois vous faire part d’une petite recherche que j’ai effectué aujourd’hui, avec l’aide de mon collègue Cédric, sur la navigabilité des sites en Flash, et en particulier pour gérer les boutons « Suivant/Précédent » qui sont tellement problématiques pour les développeurs, et pourtant tellement utilisés intuitivement par les utilisateurs !

Si vous jetez un oeil à ce site : Le Coq Sportif, vous allez voir qu’il s’agit d’un site d’eCommerce en Flash, chose déjà suffisamment rare, mais avec quelques petits détails qui font toute la différence :

• Déjà, on peut utiliser le clic droit, pour aller à tout moment sur son panier ou valider sa commande. Pas évident au départ, tellement le réflexe est « contre nature » pour une navigation Web, mais pourtant tellement pratique !
• L’aspect dynamique du Flash permet de passer d’une vignette à l’autre de manière fluide, et de visualiser d’un coup d’oeil quels sont les tailles dispos et les autres
• Et surtout, une astuce de la mort qui tue permet de gérer proprement la navigabilité.

Pour ce faire, le site va réécrire dynamiquement l’URL au fur et à mesure de votre navigation…dans l’interface Flash, ce qui par définition ne devrait pas faire changer l’URL. Ainsi, il « suffit » de générer des URL permettant de réafficher des points précis dans l’interface Flash, et on peut ensuite utiliser le mécanisme classique d’historique du navigateur.

Autre avantage non négligeable pour les SEO : en multipliant ainsi les URL pour une seule et même interface Flash, on facilite ainsi le boulot des robots de moteurs de recherche, qui vont ainsi pouvoir naviguer sur l’interface, alors que le Flash est si difficile à référencer d’habitude.

Je n’ai pas encore testé, mais une page recensant les diverses URL « d’entrée » vers le Flash devrait pas mal faciliter le boulot. Ce mécanisme, cumulé à celui d’Adobe permettant de « parser » le texte d’un .swf, devrait permettre des choses intéressantes du côté du référencement.

Pour en revenir à cette génération d’URL pointant au coeur d’une application Flash, on peut utiliser ce type de framework qui est tout spécialement conçu pour !

1) Le mystère des comparaisons de String

La classe la plus banale de Java : String. Dans la Javadoc, ils précisent bien que

s= »coucou »;

et

s=new String(« coucou »);

sont équivalents.

Eh ben…regardez :

String s1= »bob »;
String s2= »bob »;
String s3=new String(« bob »);
if(s1==s2)
System.out.println(« ca marche sans le new »);
if(s1==s3)
System.out.println(« ca marche avec le new »);

Le premier test fonctionne, et pas le second ! Je sais qu’il ne faut pas faire l’erreur d’utiliser ==, mais bien .equals, mais là il s’agit de comparer les pointeurs.. Je m’étonne en fait que le premier test fonctionne.

2) L’héritage perdu

Soit une classe mère :

public class Mere {
public Mere()
{
System.out.println(« mere sans param »);
}

public Mere(String s)
{
System.out.println(« mere « +s);
}
}

et une classe Fille…vide :

public class Fille extends Mere
{
}

Testez :

Mere m=new Mere();
Mere m2=new Mere(« bla »);
Fille f=new Fille();
//Fille f2=new Fille(« bli »);

La dernière ligne est en commentaire, et pour cause : elle provoque une erreur du compilateur ! « Constructeur inexistant ». En revanche, la ligne « Fille f=new Fille() » appelle bien le constructeur de la classe mère, et pas un constructeur implicite. Pourquoi hériter d’un constructeur et pas de l’autre ?

Alors, vos avis ?

Update : j’ai compris pour le cas 2 ! Merci à Jib pour m’avoir aiguillé sur la voie de la rédemption !

Alors, je vous explique : ce qui me paraissait super bizarre, c’est que Fille sache bien exploiter le constructeur sans paramètre de la classe mère, mais pas l’autre ! C’était quoi, de la ségrégation ?

Je ne voyais pas en quoi le principe du « constructeur implicite » jouait , puisqu’on héritait bien de quelque chose, il n’y avait rien d’implicite. Jib a toutefois bien fait d’insister. Suivez le raisonnement exact de Java :

1. On n’hérite PAS des constructeurs lors d’un mécanisme d’héritage. Je l’avoue, je l’avais complètement oublié. Mais ce qui m’a aidé dans cet oubli, c’est le fait que la classe Fille « hérite » quand même d’un des constructeurs de la classe mère, du moins en apparence. Mais…
2. …vu que la classe fille n’hérite d’aucun constructeur, et qu’elle n’en possède pas, la règle rappelée par Jib s’applique : un constructeur implicite est mis en place.
3. Deuxième effet kiss-cool : le constructeur implicite, contrairement à ce que je croyais, ne reste pas sans rien faire. En fait, il a un rôle bien particulier : il appelle, implicitement, le constructeur sans paramètre de la classe mère.
4. Vu que la classe mère a quant à elle un constructeur sans paramètre bien réel, ce dernier est appelé. CQFD.

Voilà pourquoi ma classe Fille se retrouve « héritant » du constructeur sans paramètre de ma classe Mere, et pas de l’autre. Tout simplement parce qu’il n’y a pas d’héritage direct des constructeurs, mais une construction implicite qui appelle implicitement un constructeur parent. Pffiou !

Update 2 : Vu que, quand yen a marre, ya Malabar, j’ai employé les grands moyens pour comprendre cette histoire d’affectation de String, et ça a été l’occasion pour moi de faire un truc que je voulais faire depuis longtemps : décompiler du Bytecode !

On utilise pour cela l’instruction javap, qui prend en entrée un fichier .class, et qui vous le « désassemble » pour obtenir un byte code plus ou moins lisible.

Tentons de désassembler le code suivant :

String s1= »bob »;
String s2= »bob »;
String s3=new String(« bob »);

Cela donne le code suivant (j’ai fait trois paragraphes correspondant aux 3 instructions) :

0: ldc #16; //String bob
2: astore_1

3: ldc #16; //String bob
5: astore_2

6: new #18; //class java/lang/String
9: dup
10: ldc #16; //String bob
12: invokespecial #20; //Method java/lang/String. »<init> »
15: astore_3

On a donc la réponse : les deux chaînes s1 et s2 pointent bel et bien sur le même espace mémoire (#16) tout simplement parce que le compilateur Java a su détecter que la chaîne utilisée était bien la même dans les deux cas. Pour preuve, en ligne 10, c’est à nouveau cette adresse qui est chargée dans le registre pour pouvoir appeler le constructeur de String (j’ai essayé de faire 3 tonnes d’affectations entre la déclaration de s1 et s2, ça marche pareil, il retombe sur ses pattes).

Autre enseignement de ces quelques lignes : dans les affectations de type s= »toto », il n’y a pas de construction explicite de l’objet String qui est effectuée (pas d’appel à « new »), mais simplement le chargement d’une référence vers un espace mémoire représentant ce String, et qui va être partagé par tous ceux qui contiennent la même chaine.

Pour les développeurs débutants, c’est super piégeux, car le fait que s1==s2 donne le résultat attendu peut faire croire qu’on est dans le bon, alors que ça ne marchera plus dès lors qu’on manipulera des String générés par des éléments externes (une lecture dans une base, par exemple).

Pour les développeurs un peu plus aguerris, ça nous amène à la réflexion suivante : en fait, les objets String ne sont pas immuables par une volonté particulière, mais simplement par nécessité : il serait super risqué de donner la possibilité de modifier ces « espaces mémoires mis en commun ».

Reste une question : est ce que ces espaces communs sont des instances de String à part entière, ou bien des simulâcres de classes pour donner une cohérence à l’organisation « 100% classes » de String ? Je ne sais pas encore…

Update 3 : une doc intéressante fournie par un de mes stagiaires, merci Michel !

On y apprend deux choses :

• String est vraiment une classe à part, elle est considérée comme étant un « literal », au même titre qu’un type scalaire (int…), son comportement est donc assez différent d’une classe classique que l’on instancie
• L’article m’a aiguillé sur la méthode intern() de la classe String qui confirme ce que je pensais : Java gère en interne un « pool » de chaînes de caractères afin de repérer les chaînes similaires et éviter les doublons d’instance.

A noter qu’apparemment, C# fonctionne de la même manière.