Passer un paramètre à une page qu'on accède

Version imprimable

03/08/2015, 10h15
doons

Passer un paramètre à une page qu'on accède
Bonjour,

J'aimerais savoir comment je peux, depuis une page, en cliquant sur un lien, transmettre un paramètre à la page à laquelle j'aimerais accéder.
J'ai bien utilisé jusqu'à maintenant
Code:

1 2 <f:param name="readOnly" value="true" />
Mais ça ne me satisfait pas car il suffit de changer l'url pour ne plus être en lecture seule.

Y'a-t-il un autre moyen ?
Merci pour votre aide
04/08/2015, 22h52
tchize_

Faut pas passer par un lien, mais par une action. Dans l'action tu peux définir des flags en scope session précisant si on peux lire et ensuite, après la redirection, lire ces valeurs dans la session pour connaitre l'état.

Merci pour ta réponse, ça semble bien fonctionner :-)

Etant pas encore très à l'aise dans le domaine, j'ai fais comme je pensais être une bonne pratique.
Peux-tu juste stp checker que c'est en ordre ? Même si ça fonctionne, je n'aimerais pas partir sur de mauvaises pratiques.

De plus, est-ce qu'il ne faudrait pas vider la session après récupération des valeurs dans init() ? Car à force ça risque de charger la mémoire .... non?

La page xhtml:

Code:

1
2
3
4
5
6
7
8
9
10
 
<p:commandLink action="#{gestionSocietesForm.openSociete}" styleClass="ui-icon ui-icon-action-detail" >
	<f:setPropertyActionListener target="#{gestionSocietesForm.lectureSeule}" value="#{true}"/>
	<f:setPropertyActionListener target="#{gestionSocietesForm.idSociete}" value="#{societe.id}"/>
</p:commandLink>
 
<p:commandLink action="#{gestionSocietesForm.openSociete}" rendered="#{not gestionSocietesForm.userLectureSeule}" styleClass="ui-icon ui-icon-action-modifier" >
	 <f:setPropertyActionListener target="#{gestionSocietesForm.lectureSeule}" value="#{false}"/>
	 <f:setPropertyActionListener target="#{gestionSocietesForm.idSociete}" value="#{societe.id}"/>
</p:commandLink>

Le bean correspondand:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public void openSociete() {
	FacesContext context = FacesContext.getCurrentInstance();
	try {
		ExternalContext externalContext = context.getExternalContext();
 
		HttpSession session = ((HttpServletRequest) externalContext
			.getRequest()).getSession();
 
		session.setAttribute("readOnly", this.readOnly);
		session.setAttribute("societeId", this.id);
 
		String urlOriginale = externalContext.getRequestContextPath() + "/secured/parametrage/gestion/societe/saisirSociete.xhtml";
		externalContext.redirect(urlOriginale);
	} catch (IOException e) {
		System.out.println(e);
	        context.addMessage(null, new FacesMessage(e.getMessage()));
	}
}

Et le bean de la page en lecture seule:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
        @PostConstruct
	public void init() {
		FacesContext context = FacesContext.getCurrentInstance();
		ExternalContext externalContext = context.getExternalContext();
 
		HttpSession session = ((HttpServletRequest) externalContext
				.getRequest()).getSession();
 
		Integer idSociete = (Integer) session.getAttribute("societeId");
		lectureSeule = (Boolean) session.getAttribute("readOnly");
 
		if (idSociete != null) {
			currentSociete = m_societeService.getSociete(idSociete);
		} else {
			currentSociete = new Societe();
		}
	}

Merci beaucoup pour ton aide

Cette partie de code est assez inutile
Code:

1 2 3 4 5 6 7 8 9 public void init() { FacesContext context = FacesContext.getCurrentInstance(); ExternalContext externalContext = context.getExternalContext(); HttpSession session = ((HttpServletRequest) externalContext .getRequest()).getSession(); Integer idSociete = (Integer) session.getAttribute("societeId"); lectureSeule = (Boolean) session.getAttribute("readOnly");
tu récupère des infos de sessions pour les mettres manuellement dans des attributs, mais JSF est déjà capable de le faire tout seul avec des annotation sur les champs ou sur les getters:
Code:

1 2 3 4 @ManagedProperty("#{session.societeId}") private int idSociete; @ManagedProperty("#{session.readOnly}") private boolean lectureSeule;
Maintenant, je suppose que quelque part tu définis societeId et readOnly dans la session, probablement pendant le login. Dans ce cas il y a une manière encore plus claire de faire avec CDI+JSF (standard dans les dernier J2EE), qui t'évite à multiplier les accès manuels à la session et en plus valide que les clés sont correctes:
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 @javax.enterprise.context.SessionScoped //attention, ce n'est pas l'annotation JSF du même nom! public class MonProducteurDeConfig implements Serializable { private Integer idSociete; private Boolean readonly; @Produces @Named("societeId") public Integer getIdSociete() { return idSociete; } public void setIdSociete(Integer id) { this.idSociete = id; } @Produces @Named("readOnly") public Boolean getReadonly() { return readonly; } public void setReadonly(Boolean ro) { this.readonly = ro; } }
Code:

1 2 3 4 5 6 7 8 9 10 11 @javax.enterprise.context.RequestScoped @Named("gestionSocietesForm") public class GestionSocietesForm { @Inject @Named("readOnly") private boolean lectureSeule; @Inject @Named("societeId") private int societe; //..... }
et dans ton Bean de login ou je sais pas trop quoi:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 @javax.enterprise.context.RequestScoped public LoginBean { @Inject private MonProducteurDeConfig config; //.... public String loginAction(){ //... config.setReadonly(...); config.setIdSociete(....); return "OK"; } //... }
L'avantage de CDI c'est que tu peux injecter les bean dans tes servlets si besoin (genre des servlets de downloads), que tu peux accéder à des EJB et au transaction manager JPA

Dans cette config, MonProducteurDeConfig est capable de générer des valeur (readonly, idSociete), ce qui est précisé via les @Produces et tout les bean CDI peuvent accéder à ces valeurs pour se les faire injecter.

Code:

1
2
3
4
<p:commandLink action="#{gestionSocietesForm.openSociete}" rendered="#{not gestionSocietesForm.userLectureSeule}" styleClass="ui-icon ui-icon-action-modifier" >
      <f:setPropertyActionListener target="#{gestionSocietesForm.lectureSeule}" value="#{false}"/>
      <f:setPropertyActionListener target="#{gestionSocietesForm.idSociete}" value="#{societe.id}"/> 
</p:commandLink>

C'est se compliquer la vie, pourquoi ne pas appeler une méthode avec des paramètres

Code:

1
2
 
<p:commandLink action="#{gestionSocietesForm.openSociete(false, societe.ID)}" ... />

06/08/2015, 08h05
doons

Super, merci beaucoup pour ces précisions.

Je définis societeId et lectureSeule dans la page d'affichage de la liste des sociétés, dans la méthode appelée lorsque tu cliques pour voir le détail d'une société. J'ai ce mécanisme dans beaucoup de page, en fait toutes celles qui permettent de saisir des éléments et de les consulter. Je vais donc créer un ProducteurDeConfig global à toutes ces pages.

Petit détail, tes beans ont les annotations "@Named" et "@javax.enterprise.context.RequestScoped, ..." alors que les miens ont "@ManagedBean(name = "saisirSocieteForm")" et "@javax.faces.bean.ViewScoped, RequestScope, ....", le problème est que j'utilise beaucoup de ViewScoped (car c'est la scope qui fonctionne le mieux lors de la saisie de mes formulaires - requestScope me faisisait perdre des données pendant le cycle saisie - validation ....), non disponible avec CDI. Est-ce que cela a une grande importance d'utiliser l'un ou l'autre ?

Juste encore 1 petite chose :

- Est-ce qu'il ne faut pas vider la session de toutes ces variables après lecture, au risque de saturer la mémoire en ayant beaucoup d'utilisateurs si on ne le fait pas ?

@Obuttelin : Merci, c'est plus pratique avec les paramètres de méthode :-)
06/08/2015, 23h32
tchize_

a partir de JSF 2.2 tu as @javax.faces.view.ViewScoped qui est reconnu par CDI, à ne pas confondre avec javax.faces.bean.ViewScoped (pourquoi faire simple quand on peux tapper des annotations dans plein de packages différents hein...)
07/08/2015, 08h56
OButterlin

A noter également qu'avec la version JSF 2.1, la phase d'initialisation d'un ViewScoped est plus que douteuse, à éviter absolument s'il y a un binding de composant dans le managedBean sous peine d'avoir de grosses fuites de mémoire.

Sinon, on a également le CustomScoped qui permet de faire ce qu'on veut, il existe pas mal d'exemple sur le net pour faire l'équivalent du ConversationScoped ;)
10/08/2015, 13h49
doons

Super, merci beaucoup pour vos explications.

Juste encore :

Est-ce qu'il ne faut pas vider la session de toutes ces variables après lecture, au risque de saturer la mémoire en ayant beaucoup d'utilisateurs si on ne le fait pas ?
11/08/2015, 09h29
OButterlin

Grosse question en effet...
Dans la mesure où les objets qu'on met en session "devrait" être Serializable, je pense que la plupart des serveurs s'occuperont tout seul de vider la mémoire si besoin... mais bon, si on sait qu'on peut purger l'objet, pourquoi ne pas le faire ;)
12/08/2015, 07h23
doons

ok merci :-)