Récuperer la clé d'un FacesMessage

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/03/2009, 16h12
issamjet

Récuperer la clé d'un FacesMessage

Salut,

je suis entrain de réaliser un générateur de fichiers de tests pour les applications JSF.
La tache la plus importante est de récupérer les scénarios de chaque utilisateur lors de sa navigation dans une application JSF.
La difficulté que j'ai trouvée est comment récupérer les clés des messages(FacesMessage)
Par exemple :
quand JSF génère un message ("Value is required") mon générateur doit automatiquement détecter la clé de ce message qui est ("javax.faces.component.UIInput.REQUIRED").

Merci.
30/03/2009, 16h48
tchize_

ca risque d'être impossible à faire (si deux clés donnent le même message final, impossible de distinguer). Pourquoi ne pas simplement te baser sur le texte dans une langue et imposer cette langue lors du test?
30/03/2009, 16h59
yciabaud

Ils sont dans le contexte JSF, tu itere sur tous les messages et tu teste si la clef corresponds.

cf. FacesContext.getMessages()
30/03/2009, 17h03
issamjet

Citation:

Envoyé par tchize_

ça risque d'être impossible à faire (si deux clés donnent le même message final, impossible de distinguer). Pourquoi ne pas simplement te baser sur le texte dans une langue et imposer cette langue lors du test?

Merci tchize_ pour la réponse.
En fait, mon travail consiste à récupérer les clés car les messages devront être personnalisés par l'utilisateur il peut écrire n'importe quoi comme message d'erreur mais la clé reste toujours invariante.
Ma mission consiste à pouvoir récupérer la clé lors de l'envoi du message d'erreur par JSF et non pas à partir du message lui même pour la raison que vous avez mentionnée.
30/03/2009, 17h06
issamjet

Citation:

Envoyé par yciabaud

Ils sont dans le contexte JSF, tu itere sur tous les messages et tu teste si la clef corresponds.

cf. FacesContext.getMessages()

Merci yciabaud

J'ai pensé à ça mais dans ce cas on peut arriver dans une situation où il y a le même message pour deux clés différentes.
30/03/2009, 19h14
tchize_

tu veux les messages avant ou après le rendu? Si tu veux personnaliser les messages d'erreurs, c'est déjà standard dans JSF. Faut fouiner un peux dans les specs, y a moyen de fournir ton propre ressource bundle à JSF et les noms des clés est standard. Si tu veux la liste des messages d'erreurs pour la page courante, c'est de fait comme a dit yciabaud. Si tu veux parser la page pour choper les erreur, bonne chance :-)
31/03/2009, 10h56
issamjet

Citation:

Envoyé par tchize_

tu veux les messages avant ou après le rendu? Si tu veux personnaliser les messages d'erreurs, c'est déjà standard dans JSF. Faut fouiner un peux dans les specs, y a moyen de fournir ton propre ressource bundle à JSF et les noms des clés est standard. Si tu veux la liste des messages d'erreurs pour la page courante, c'est de fait comme a dit yciabaud. Si tu veux parser la page pour choper les erreur, bonne chance :-)

Merci

En fait je veux récupérer automatiquement la liste des clés des messages d'erreurs générés pour la page courante.
Le fait de parser le fichier de ressources presente un probleme car un developpeur JSF peut personnaliser ses messages comme il veut, donc on peut trouver le même message qui a deux clés différentes. Par exemple:
javax.faces.component.UIInput.REQUIRED=entrer une valeur ici
Et
javax.faces.converter.NumberConverter.NUMBER=entrer une valeur ici.

Le problème, c'est que les messages sont générés par les composants de la manière suivantes (myfaces, _MessagesUtils.java):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40     static void addErrorMessage(FacesContext facesContext,
41                                 UIComponent component,
42                                 String messageId)
43     {
44         facesContext.addMessage(component.getClientId(facesContext),
45                                 getMessage(facesContext,
46                                            facesContext.getViewRoot().getLocale(),
47                                            FacesMessage.SEVERITY_ERROR,
48                                            messageId,
49                                            null));
50     }
51
64     static FacesMessage getMessage(FacesContext facesContext,
65                                    Locale locale,
66                                    FacesMessage.Severity severity,
67                                    String messageId,
68                                    Object args[])
69     {
70         ResourceBundle appBundle;
71         ResourceBundle defBundle;
72         String summary;
73         String detail;
74
75         appBundle = getApplicationBundle(facesContext, locale);
76         summary = getBundleString(appBundle, messageId);
//.......
114         if (args != null && args.length > 0)
115         {
116             MessageFormat format;
117
118             if (summary != null)
119             {
120                 format = new MessageFormat JavaDoc(summary, locale);
121                 summary = format.format(args);
122             }
//.....
130
131         return new FacesMessage(severity, summary, detail);
132     }

Comme tu le vois, la clé n'est stockée nulle part, on traduit directement le message d'erreur dans la langue de l'utilisateur.

Citation:

Envoyé par tchize_

Le problème, c'est que les messages sont générés par les composants de la manière suivantes (myfaces, _MessagesUtils.java):

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40     static void addErrorMessage(FacesContext facesContext,
41                                 UIComponent component,
42                                 String messageId)
43     {
44         facesContext.addMessage(component.getClientId(facesContext),
45                                 getMessage(facesContext,
46                                            facesContext.getViewRoot().getLocale(),
47                                            FacesMessage.SEVERITY_ERROR,
48                                            messageId,
49                                            null));
50     }
51
64     static FacesMessage getMessage(FacesContext facesContext,
65                                    Locale locale,
66                                    FacesMessage.Severity severity,
67                                    String messageId,
68                                    Object args[])
69     {
70         ResourceBundle appBundle;
71         ResourceBundle defBundle;
72         String summary;
73         String detail;
74
75         appBundle = getApplicationBundle(facesContext, locale);
76         summary = getBundleString(appBundle, messageId);
//.......
114         if (args != null && args.length > 0)
115         {
116             MessageFormat format;
117
118             if (summary != null)
119             {
120                 format = new MessageFormat JavaDoc(summary, locale);
121                 summary = format.format(args);
122             }
//.....
130
131         return new FacesMessage(severity, summary, detail);
132     }

Comme tu le vois, la clé n'est stockée nulle part, on traduit directement le message d'erreur dans la langue de l'utilisateur.

Merci
Le problème maintenant est plus claire.
Une seule chose, d'où JSF récupère le paramètre messageId?

31/03/2009, 11h56
tchize_

c'est le paramètre passé en méthode à l'argument. Le code que je te montre est spécifique à une version de myfaces, comem ce sont des classes internes, elle peuvent changer à tout moment. Ton message id est juste passé en paramètre par le composant lorsqu'il a un problème dans myfaces. La manière dont ce message id est récupéré par le composant dépend du composant (hardcodé, calculé, constante, ....)
31/03/2009, 12h55
issamjet

Citation:

Envoyé par tchize_

c'est le paramètre passé en méthode à l'argument. Le code que je te montre est spécifique à une version de myfaces, comem ce sont des classes internes, elle peuvent changer à tout moment. Ton message id est juste passé en paramètre par le composant lorsqu'il a un problème dans myfaces. La manière dont ce message id est récupéré par le composant dépend du composant (hardcodé, calculé, constante, ....)

D'accord, mais est ce que je peux intercepter le message lors de son envoi par jsf comme ça je peux connaitre la cause et parsuite la clé.
31/03/2009, 13h18
tchize_

le "message" envoyé à JSF par le composant est un object FacesMessage contenant du pur texte déjà mis en forme opur l'utilisateur (locale correct, ressourcebundle utilisé, éventuellement MessageFormat utilisé), y a rien d'autre à intercepter.
31/03/2009, 14h46
issamjet

Citation:

Envoyé par tchize_

le "message" envoyé à JSF par le composant est un object FacesMessage contenant du pur texte déjà mis en forme opur l'utilisateur (locale correct, ressourcebundle utilisé, éventuellement MessageFormat utilisé), y a rien d'autre à intercepter.

OK. Vous me dites donc que la seule solution est de chercher la clé en parsant le fichier de ressources en supposant qu'il n'y a pas de messages redondants.
31/03/2009, 16h40
tchize_

je me dit que la solution serait surtout de se passer du besoin d'avoir à connaitre les clé, j'ai du mal a comprendre pourquoi tu veux retrouver les clés associées aux faces message. Parce que, même en parsant le fichier de ressources, va y avoir des trucs dur à interprêter à l'envers:
http://svn.apache.org/repos/asf/myfa..._fr.properties
31/03/2009, 17h45
issamjet

Citation:

Envoyé par tchize_

je me dit que la solution serait surtout de se passer du besoin d'avoir à connaitre les clé, j'ai du mal a comprendre pourquoi tu veux retrouver les clés associées aux faces message. Parce que, même en parsant le fichier de ressources, va y avoir des trucs dur à interprêter à l'envers:
http://svn.apache.org/repos/asf/myfa..._fr.properties

Mon projet consiste à intercepter la trace d'un utilisateur et générer automatiquement un fichier contenant cette trace avec tous les paramètres saisis par l'utilisateur,tous les clés des messages d'erreurs....
Ce fichier sera reconnu par le frameWork JSF UNIT et tout le scénario sera rejoué tout en testant est ce que la navigation est la même, est ce que les messages d'erreurs sont les mêmes(nécessité de la clé car le contenu des messages peut être modifié et pas la clé)
31/03/2009, 20h00
tchize_

si tu stocke la langue de l'utilisateur et que tu sais quel ressource bundle est déployé (je suppose que tu le change pas tous les jours), rejouer le scénar rejouera théoriquement les mêmes messages d'erreur, je vois donc pas la nécessiter de ce casser le cul à essayer de peut être arriver à récupérer correctement les clés, alors que tu peux te baser directement les messages. Au pire, quand tu crée ton test unitaire, si c'est mais vraiment nécessaire, t'ouvre toi meme le ressource bundle pour trouver tes clés.
01/04/2009, 10h11
issamjet

Citation:

Envoyé par tchize_

si tu stocke la langue de l'utilisateur et que tu sais quel ressource bundle est déployé (je suppose que tu le change pas tous les jours), rejouer le scénar rejouera théoriquement les mêmes messages d'erreur, je vois donc pas la nécessiter de ce casser le cul à essayer de peut être arriver à récupérer correctement les clés, alors que tu peux te baser directement les messages. Au pire, quand tu crée ton test unitaire, si c'est mais vraiment nécessaire, t'ouvre toi meme le ressource bundle pour trouver tes clés.

Merci
j'ai commencé à faire ça.
je veux savoir est ce que je peux transformer ce fichier en HashMap (est ce qu'il y a des méthodes implémentées utilisables) à la place de le parser.
01/04/2009, 12h41
tchize_

si tu veux pas t'emmerder à parser et que tu ne stocke que des string dans ta map, utilise la sérialisation pour l'écrire dans une fichier ton scénar :)
02/04/2009, 09h49
issamjet

Mais le problème reste pour les messages de validation des formulaires que le développeur les crée lui même il les lance lors de la validation selon son métier.
02/04/2009, 10h15
tchize_

et alors, tu va rejouer, normalement, le test avec les même métiers

Voir 40 message(s) de cette discussion en une page