Discussion :

[JWillow]

Bonjour,

Voilà j'aimerais savoir comment bien gérer les beans en session ?
Pour être plus précis j'ai actuellement pour 1 page (jsf) 1 Controller (scope session). Je navigue de page en page donc plein de controller sont mis en session mais là où avec Struts celui-ci géré tous ça (la suppression des forms et des controller en session lorsqu'on change de page) ici tous les controller restent en session. Donc qu'elle est la bonne pratique pour retrouver un comportement proche de Struts ? Dans tous les exemples que je peux trouver c tjs une ou deux pages qui pointent vers le même controller. Il me semble que cet aspect n'est pas souvent abordé.

PS : Technique je sais comment mettre un bean en session à null mais c cette action manuellement plus le fait de devoir gérer seul de quelle controller on vient qui me gène.

[Shivan]

Pour ma part, j'ai un controller en request pour chaque page. Et un controller globale en session pour toutes l'appli. Les controller en request piochent dans le controller session. Et j'utilise aussi l'injection de bean pour passer certaines infos d'un controller request à un autre.

[ouedmouss]

Pour ma part j'utilise le composant t:savestate de myfaces.
C'est une bonne alternative au session bean

[ruda.tom]

je suis très intéressé par cette question. Je trouve également que ces aspets de conception ne sont pas beaucoup abordés (ou j'ai pas cherché assez... ).

En plus des solutions de Shivan et ouedmouss, j'ai également attendu certains utiliser plusieurs beans pour chaque page, une par fonctionnalité de la page.

Il serait vraiment intéressant d'avoir d'autres avis éclairés sur la question. Peut-être y a t il des cas d'utilisations appropriés pour chacune des solutions citées.
A votre avis ?

[*alexandre*]

A mon avis la solution le plus propre est d'un bean par page en supprimant l ajout des composants JSF dans l initalisation

ce que j aimais justement pas sur Struts c'est la définition d'une classe par action alors que celles-ci sont liés au même objet

c'est l anti these de la prog objet ou tu détermines une classe par action

edit ca represent plus un pattern command mais c'est tellement inutile ...

une application devrait comporter qu un seul controller qui se charge de dispatcher les actions (donc dans ce sens je rejoins Shivan)

[ruda.tom]

Qu'entends tu par "en supprimant l ajout des composants JSF dans l initalisation
" ?

Tu les mets en session ou en requete tes beans ?

[*alexandre*]

je parlais du binding

[ruda.tom]

Shivan, peux-tu m'expliquer comment tu fais pour que tes beans en request puissent accéder à ton bean en session ?

[ouedmouss]

J'imagine que pour acceder a la session beans on peut avoir une classe du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
public class Utils {
    public static Object getSessionBean(String nomBean){
        FacesContext ctx=FacesContext.getCurrentInstance();
        ExternalContext etx=ctx.getExternalContext();
        HttpSession session=(HttpSession) etx.getSession(true);
        return session.getAttribute(nomBean);
    }
 
}

Et dans un beans on pourra appeler

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
   MonBeanSession beanSession=(MonBeanSession)Utils.getSessionBean("nom du bean session");

[mbouzouita]

bonjour a tous,

je suis d'acord avec ouedmouss, et je fait presque le meme principe que lui mais j'utilise des variables qui sont des paramaetres ou autres dans la session, ensuite
je les appelles :

FacesContext fc = FacesContext.getCurrentInstance();
ExternalContext ec= fc.getExternalContext();
int mat=((UserInfo) ec.getSessionMap().get("UserInfo")).getMat();

et j'utilise un bean pour chaque page

[ruda.tom]

Je crois que je vais reprendre l'idée du bean transverse en session. En plus ça permet de controler facilement tout ce qui est mis en session, c'est un point non négligeable.

[*alexandre*]

pas besoin d un tel appel si ton bean est correctement définit dans ton applicationContext et si tu appliques la règle un bean par page donc aucune invocation nécessaire