Oui effectivement, j’ai posé mes exemples de tête sans aller vérifier dans mes vieilles source comment j’avais fait la dernière fois.

Je suis content qu’on ai cette solution qui me parait plus simple quand même.

Non.

En tout cas, pas dans l’exemple de code que vous donnez. Prenons un autre exemple :

public enum EnumWithField {

A(System.currentTimeMillis());

private long value;

private EnumWithField(long value) {
this.value = value;
}

public long getValue() {
return value;
}
}

Dans cette première enum, le champ value est fixé à la construction de l’enum, qui a lieu au chargement de la classe de l’enum.

Alors que :

public enum EnumDynamic {
A;
public long getValue() {
return System.currentTimeMillis();
}
}

Ici, la valeur renvoyée value suivant le moment de l’appel. Il suffit de tester :

public static void main(String[] args) throws Exception {
System.out.println(« Field 1:  » + EnumWithField.A.getValue());
System.out.println(« Dynamic 1:  » + EnumDynamic.A.getValue());
Thread.sleep(1337);
System.out.println(« Field 2:  » + EnumWithField.A.getValue());
System.out.println(« Dynamic 2:  » + EnumDynamic.A.getValue());
}

Cela affiche :

Field 1: 1275041432914
Dynamic 1: 1275041432919
Field 2: 1275041432914
Dynamic 2: 1275041434256

Cependant, votre idée de base reste intéressante, à condition de stocker la clé et de déterminer le bon message dynamiquement au moment de l’appel :

public enum Toto {
PREMIER(« PREMIER »), SECOND(« SECOND »);
private String name;

private Toto(String s) {
name = s;
}

public String toString() {
return ResourceBundle.getBundle(« MyResource »).getObject(name).toString();
}
}

Je ne vois pas où est le problème. Je pense que ca fait beaucoup moins de code à écrire et ca n’est pas moins optimisé il me semble.

Pour rentrer plus dans les détails, les valeurs des enums sont instanciées au chargement de la classe et non modifiable. J’entends par « non modifiable » que l’instance ne peut être remplacée par une autre.

Par contre il est possible de modifier la valeur des champs d’une enum (champ « message » dans l’exemple). Mais il faut à tout prix éviter ce genre de comportement, surtout dans une application distribuée/multi-utilisateur (j’ai des mauvais souvenirs de ces erreurs lors d’une de mes missions…).

Par convention, il faut éviter de modifier les valeurs des champs d’une enum à la volée.

@Philippe Voncken

Ce que vous écrivez peut fonctionner dans un environnement Java standalone mono-utilisateur. Mais ceci ne colle pas du tout avec la problématique expliquée dans cet article (Spring MVC est utilisé pour faire du Web => application multi-utilisateur).

Arrêtez moi si je me trompe, mais les éléments d’une enum sont construits au chargement de la classe.

Autrement dit, au chargement de la classe (l’enum), PREMIER et SECOND vont être instanciés. Et le paramètre de constructeur va être valorisé. Ce qui signifie que Toto, dans ton exemple, aura des valeurs qui dépendront de la locale AU MOMENT DU CHARGEMENT DE LA CLASSE, et non modifiables par la suite.

Ici, c’est tout le contraire : la locale va dépendre de la langue du client web… Donc cela peut varier à chaque requête.

Faut pas oublier qu’une enum, c’est grosso modo une classe portant plusieurs instances statiques d’elle même.

Je réagis peut-être un peu vivement, mais j’aimerai éviter des erreurs au futurs lecteurs de cet article . Encore une fois, si je fais erreur, tell me

Voici le code donc :
public enum Toto {
PREMIER(ResourceBundle.getBundle(« MyResource »).getObject(« PREMIER »)),
SECOND(ResourceBundle.getBundle(« MyResource »).getObject(« SECOND »));
private String name;
private Toto(String s) {
name = s;
}
public String toString() {
return this.name;
}
}

Avec Java de base on peut déjà afficher une énumération internationalisée.

(Je vous file un code de tête donc il est possible qu’il faille corriger des fautes d’ortho)

public enum Toto {
PREMIER(ResourceBundle.getBundle(« MyResource »).getObject(« PREMIER »)),
SECOND(ResourceBundle.getBundle(« MyResource »).getObject(« SECOND »));
private String name;
private Toto(String s) {
name = s;
}
}

Et voilà, grâce au resource bundle on bénéficie de l’internationalisation sur l’enum.

Je pense que c’est plus simple et plus élégant que l’exemple de ce billet.

Cordialement,
Philippe

<select id="title" name="title">
  <option value="Mister">Monsieur</option>
  <option value="Madam">Madame</option>
  <option value="Miss">Mademoiselle</option>
</select>

La valeur soumise par le formulaire correspondra au nom de l’élément de l’énumération. Il est vrai que le code semble asymétrique, mais fonctionne.

Je n’ai pas trouvé de moyen plus élégant pour répondre à cette problématique simple, la solution du property editor présente l’avantage d’être générique. Pour paraphraser l’introduction : « Je suis preneur de toute autre meilleure solution »

Concernant la seconde remarque, je ne suis pas persuadé que de remplacer « clazz » par « enumerationClass » apporte une meilleure lisibilité du code. L’autodocumentation n’est à mon avis pas suffisante ici…

Erwan (Xebia)

J’ai une question : dans PrintableEnumerationEditor.getAsText(), lorsque la value est une PrintableEnumeration et qu’un code existe, c’est le message traduit qui est retourné. Dans le cas contraire, c’est le nom de l’élément dans l’enum.

Cependant, dans PrintableEnumarationEditor.setAsText(), c’est systématiquement le nom de l’élément dans l’enum qui permet de retrouver l’instance (Enum.valueOf(clazz, text))

Il semble que le comportement est asymétrique. Quand la valeur dans le formulaire est « Monsieur », comment fais-tu pour retrouver Title.Mister après un POST ?

Est-ce que j’ai loupé quelque chose ? Etant donné qu’un champ HTML option peut comporter à la fois un nom et une valeur, c’est peut-être là l’explication ?

Je m’en vais regarder la doc sur les PropertyEditor / comment ils sont utilisés pour rendre un form:select … Mais si quelqu’un en sait plus, n’hésitez pas !

Plus anecdotique, à propos du nom de variable « clazz », je suis en train de lire « Clean code », et, je cite : « Les programmeurs se créent des problèmes lorsqu’ils écrivent du code uniquement pour satisfaire le compilateur ou l’interpréteur. [...] C’est par exemple le cas de la pratique véritablement horrible qui consiste à créer une variable nommée klass [ou clazz] simplement parce que le nom class est employé pour autre chose ».

Je ne fais pas là une critique, j’emploie moi même « clazz » très couramment, sans réfléchir, notamment après l’avoir vu utilisé dans nombre de frameworks Open Source. Mais après réflexion, « clazz » est peut-être un mot clé apportant peu de sens…