Problème de navigation

Version imprimable

Bonjour,

Voici un petit problème de navigation sur lequel je m'arrache les cheveux depuis plusieurs jours.

J'ai deux pages : test.jsp et test2.jsp. Chacune contient simplement un bouton pour passer à l'autre page.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<f:view>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>test</title>
</head>
<body>
	<h:form id="formTest">
		ok <h:commandButton value="ok" action="ok" />
	</h:form>
</body>
</html>
</f:view>

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<f:view>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>test</title>
</head>
<body>
	<h:form id="formTest2">
	retour
		<h:commandButton value="retour" action="retour" />
	</h:form>
</body>
</html>
</f:view>

Côté faces-config, c'est ultra simple :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
<?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE faces-config PUBLIC "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN" "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">
<faces-config>
	<navigation-rule>
		<from-view-id>/test.jsp</from-view-id>
		<navigation-case>
			<to-view-id>/test2.jsp</to-view-id>
		</navigation-case>
	</navigation-rule>
 
	<navigation-rule>
		<from-view-id>/test2.jsp</from-view-id>
		<navigation-case>
			<to-view-id>/test.jsp</to-view-id>
		</navigation-case>
	</navigation-rule>
...

Mon problème est que lorsque je clique sur le bouton d'une page, la même page se réaffiche au lieu de basculer sur l'autre.

Pour tenter de piger ce qui se passe, j'ai créé une classe dérivée de PhaseListener :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
public class MonLifeCycleListener implements PhaseListener
{
 
	public void afterPhase(PhaseEvent arg0) {
		System.out.println("Fin   - " + arg0.getPhaseId() + " - " + arg0.getFacesContext().getViewRoot().getViewId());
	}
 
	public void beforePhase(PhaseEvent arg0) {
		System.out.println("Début - " + arg0.getPhaseId() + " - " + arg0.getFacesContext().getViewRoot().getViewId());
	}
 
	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}
}

Dans faces-config :

Code:

1
2
3
4
 
	<lifecycle>
		 <phase-listener>fr.cud.MonLifeCycleListener</phase-listener>
	</lifecycle>

Et voilà le résultat :

Code:

1
2
3
4
5
6
7
8
9
10
11
 
Début - APPLY_REQUEST_VALUES 2 - /test.jsp
Fin   - APPLY_REQUEST_VALUES 2 - /test.jsp
Début - PROCESS_VALIDATIONS 3 - /test.jsp
Fin   - PROCESS_VALIDATIONS 3 - /test.jsp
Début - UPDATE_MODEL_VALUES 4 - /test.jsp
Fin   - UPDATE_MODEL_VALUES 4 - /test.jsp
Début - INVOKE_APPLICATION 5 - /test.jsp
Fin   - INVOKE_APPLICATION 5 - /test2.jsp
Début - RENDER_RESPONSE 6 - /test.jsp
Fin   - RENDER_RESPONSE 6 - /test.jsp

On peut voir que test2.jsp est choisi à la fin de la phase INVOKE_APPLICATION... mais qu'on change d'avis avant le début de RENDER_RESPONSE !

Si quelqu'un peut m'expliquer les raisons de ce comportement bizarre 8O... il m'aidera sans doute à conserver des cheveux et ma santé mentale :arf:
Merci par avance.

PS : je tente d'ajouter des fonctionnalités à une appli que j'ai récupéré, la réponse est peut-être due à d'autres parties du faces-config que je n'ai pas fourni ici...

08/02/2010, 10h07
DevServlet

Rajoute un peu ca dans ta config du faces :

Code:

<from-outcome>retour</from-outcome>
08/02/2010, 10h28
monalizzaa

Je confirme: ton faces-config est faux
08/02/2010, 12h39
gilsword
J'ai refait un test en ajoutant le from-outcome, mais ça ne change rien.

Mais bon, c'est logique puisque cette clause est facultative (et d'ailleurs on a bien test2.jsp en fin de phase 5).

Ce qui m'énerve, c'est ce
Code:

1 2 Fin - INVOKE_APPLICATION 5 - /test2.jsp Début - RENDER_RESPONSE 6 - /test.jsp
Si je comprends bien, la navigation décide qu'il faut passer à test2.jsp, mais c'est test.jsp qui est rendu...
Un peu comme si il ne trouvait pas test2.jsp, et donc qu'il repassait à test.jsp par défaut...
08/02/2010, 13h22
tchize_

t'aurais pas un autre phase listener en route qui fait du forcing?
08/02/2010, 13h55
gilsword

Pas d'autre phase-listener ni de navigation-handler...

Pour le reste, je ne sais pas quoi chercher d'autre, je débute.
08/02/2010, 22h04
linotte91
ben en voyant ceci,
http://www.jsftutorials.net/jsf-navi...-examples.html
tout comme DevServlet j'aurais dit que ceci fonctionne:
Code:

1 2 3 4 5 6 7 8 <navigation-rule> <from-view-id>/test.jsp</from-view-id> <navigation-case> <from-outcome>retour</from-outcome> <to-view-id>/test2.jsp</to-view-id> </navigation-case> </navigation-rule>
je démarre moi aussi en JSF. Je n'ai pas eu de soucis avec ce genre de notation.
- Se pourrait'il que ton faces-config.xml ne soit pas au bon endoit ? (je crois /WEB-INF, ou autre chemin spécifié par javax.faces.CONFIG_FILES dans web.xml)
- Les fichiers *.jsp sont-ils bine à la racine de ton appli ?
09/02/2010, 11h38
gilsword

J'ai trouvé la solution... mais elle ne me plait pas.

J'ai reproduit les deux pages + faces-config dans un autre projet : cette fois ça a fonctionné correctement. 8O

Du coup, j'ai mis divers points d'arrêt, et j'ai constaté que la pile d'appel n'était pas exactement la même dans les deux cas (n° de ligne différents).

J'ai donc comparé jsf-api.jar et jsf-impl.jar dans les deux projets, et ils se sont évidemment avérés différents. En recopiant ces deux fichiers dans le projet initial, tout s'est mis à fonctionner correctement. :ccool:

Du coup, j'ai quelques questions :
- y a-t-il d'autres .jar à surveiller/remplacer (ces 2 là suffisent-ils) ?
- Comment connaître les numéros de version des lib (pas d'info de version dans les propriétés des fichiers) ?
- Les jar que j'utilisais étaient-ils vraiement buggés, ou bien le problème vient-il d'autre chose ?

Si quelqu'un peut éclairer ma lanterne...
09/02/2010, 11h40
gilsword

@linotte91 :

- le faces-config était bien au bon endroit, et bien pris en compte (sinon, il ne pointerait pas vers test2.jsp en fin de phase 5)

- les fichiers étaient bien à la racine (rép. WebContent)
09/02/2010, 11h55
Sniper37

Citation:

Envoyé par gilsword

J'ai trouvé la solution... mais elle ne me plait pas.

J'ai reproduit les deux pages + faces-config dans un autre projet : cette fois ça a fonctionné correctement. 8O

Du coup, j'ai mis divers points d'arrêt, et j'ai constaté que la pile d'appel n'était pas exactement la même dans les deux cas (n° de ligne différents).

J'ai donc comparé jsf-api.jar et jsf-impl.jar dans les deux projets, et ils se sont évidemment avérés différents. En recopiant ces deux fichiers dans le projet initial, tout s'est mis à fonctionner correctement. :ccool:

Du coup, j'ai quelques questions :
- y a-t-il d'autres .jar à surveiller/remplacer (ces 2 là suffisent-ils) ?
- Comment connaître les numéros de version des lib (pas d'info de version dans les propriétés des fichiers) ?
- Les jar que j'utilisais étaient-ils vraiement buggés, ou bien le problème vient-il d'autre chose ?

Si quelqu'un peut éclairer ma lanterne...

ça dépend des versions utilisés, tu trouvera la version dans le fichier MANIFEST dans le META-INF du jar.

je ne pense pas que les jars sont bugués, ça peut être un probleme de compatibilité de versions.
09/02/2010, 12h14
tchize_

oui probablement un méthode dont l'appel a été déplacé et qui au final se retrouve appelée deux fois. Toujours regarder les versions des jar et leur dépendances. Les sites indiquent toujours les requirements.
10/02/2010, 19h34
gilsword

Merci les gars pour ces précisions