i18n dans les EJB

Quelqu'un sait il comment récupérer le choix du langage du client dans les EJBs de façon à localiser les messages ?

En effet, si à partir de la couche web, il est relativement facile de récupérer les info du client dans le header http, comment transmettre cette info et la récupérer dans les EJBs ?

Est ce que je me trompe de pattern, la couche métier (EJB) ne doit pas retourner des messages localisés ?
C'est surtout pour les messages d'erreurs que je m'interroge. Dois Je me contenter seulement du type de l'erreur remonté par la couche métier et construire le message client dans la couche WEB ?

Je suis un peu perplexe sur le coup.

Merci d'avance de vos réponses

Citation:

---

Envoyé par hhfr

Quelqu'un sait il comment récupérer le choix du langage du client dans les EJBs de façon à localiser les messages ?

En effet, si à partir de la couche web, il est relativement facile de récupérer les info du client dans le header http, comment transmettre cette info et la récupérer dans les EJBs ?

---

En passant cette information (la session ou un bean "user" ou juste la locale) en paramètre. Je ne crois pas que les ejbs proposent quelque chose à ce niveau.

Citation:

---

Envoyé par hhfr

Est ce que je me trompe de pattern, la couche métier (EJB) ne doit pas retourner des messages localisés ?
C'est surtout pour les messages d'erreurs que je m'interroge. Dois Je me contenter seulement du type de l'erreur remonté par la couche métier et construire le message client dans la couche WEB ?

---

Personnellement, mais ça doit pouvoir être débattu, je remonterais un type d'erreur (avec dans l'exception les infos qui vont bien pour construire le message). Et je construirais le message dans la couche présentation : faire un message qui est affiché à l'utilisateur c'est de la présentation non ?

Bonjour,

Pour ma part, c'est la factory qui me transmet l'EJB qui lui associe en variable membre la locale à employer. Ce qui implique que mes EJB dérivent d'une classe de base qui contient une locale.

Mais c'est aussi la seule solution pour garantir qu'une instance donnée d'EJB traitera un problème dans une langue voulue, et l'instance suivante, éventuellement, dans une autre.

Le problème de fond est celui-ci:
1) Une page web se met à la bonne langue en choisissant d'après la directive Accept-Language du navigateur (l'utilisateur dit: je veux 'it', puis 'fr', puis 'de' en dernier choix). On sait que si rien n'est trouvé, le serveur web utilisera le bundle par défaut (un default-locale de JSF, par exemple) ou le bundle sans locale (monBundle.properties) au pire.

Cela veut dire que le moteur d'affichage de la page web et le browser, lorsqu'il y a un framework derrière (Struts, JSF...) négocient la locale qui va être réellement employée.

Et parfois, on voit sur une page qui utilise plusieurs bundles pas tous complets, que l'utilisateur aura un bout de la page en italien, puis en français, puis en allemand, puis en anglais (si c'est la locale par défaut) !!!

2) Mais quand on joint un EJB, ou que l'EJB joint un DAO pour lire/écrire des valeurs,
celui-là, il a souvent dans son code un:

Code:

---

1 2 3 4 5 6 7

public class MonEJB { private Locale locale;   public Locale getLocale() {...}; public void setLocale(...) {...}; }

---

Et que reçoit-il alors?
Italien (it).
Un seul choix.

Et s'il ne trouve pas?
Il ne peut que utiliser la locale par défaut. Car il ne connait pas, lui, le reste des préférences du navigateur. Il n'a pas reçu {it, fr, de}, mais it seulement!

Et alors, l'utilisateur se retrouve avec une page mixte Italien/Anglais là où il aurait pu avoir une gamme de choix intermédiaires.

Grunt.

Citation:

---

Envoyé par hhfr

Est ce que je me trompe de pattern, la couche métier (EJB) ne doit pas retourner des messages localisés ?
C'est surtout pour les messages d'erreurs que je m'interroge. Dois Je me contenter seulement du type de l'erreur remonté par la couche métier et construire le message client dans la couche WEB ?
Merci d'avance de vos réponses

---

Tout à fait. Ta couche métier avec ton EJB représente la logique métier. Afficher un message d'erreur n'est pas un traitement métier : c'est un traitement que la couche présentation doit prendre en charge. C'est donc ta webapp qui doit être responsable de cet affichage.

Donc retourner une ou plusieurs Exception standardisées depuis ta couche EJB et donc connu de ta webapp est pour moi la bonne solution.

L’exception peut contenir un code erreur, et en fonction de la Local de ta webapp, cette dernière pourra affiche le message d'erreur précis en question.

C'est pour moi la bonne méthode à adopter pour bien séparer la logique métier de l'affichage à l'utilisateur final.