Appeller une méthode des l'ouverture de la page

:salut:

Je souhaiterais appeller une méthode en java des l'ouverture de la page pour pouvoir initialiser un objet.

Ceux que je pourais faire,c'est d'appeller une page bidon en jsp qui récupere certaines valeurs pour récuper les informations dans la base afin de créer mon objet.Et pour finir,d'appeller ma page jsf qui aura l'objet initialisé par l'objet que j'aurais crée auparavant.

Mais, je n'aimerais pas passer par une page jsp, directement le faire à partir de ma page jsf, ou bien un autre moyen propre à jsf permettant d'initialiser qu'elle que champ de mon bean des l'ouverture de ma page
J'ai vu un sujet répondant à peut prés à mon problème ICI
Mais comment récuper l'id(parametre passé à la page) dans la fonction appellé par beforePhase?

Merci d'avance

FacesContext.getCurrentContext() te renvoie le context JSF courant, à partir de là t'as accès à la requete http et aux paramètres de celle-ci. Effectivement, un phase cycle listener, dans ton cas, est approprié.

Bon, si on reprend ton problème c'est concrètement passer en param un id à une page jsf et faire en sorte qu'elle affiche dans ses champs le détail de la ligne de la table (en gros).

Imaginons que ton objet s'appelle developpeur. tu passes page.jsf?iddev=5

Dans ton managed beau tu cre un
private Developpeur dev;

un getter et setter pour cette variable.
Dans le getter du fais :

if (dev == null)
{
// premier chargement de la page, tu va lire dans la request l'id passé et tu charges l'objet.
}
return dev;



tu ajoutes à ta page JSF un t:savestate pointant sur ton #{tongbackbean.dev}
Ainsi, même lors d'un post back ton objet sera sauvegardé dans ta page et dans le getter il ne sera jamais null. (Scope page sous seam en gros).

des questions?

merci,une petite question,je ne vois pas comment pointer mon bean.....?

Code:

---

1 2	t:savestate pointant sur ton #{tongbackbean.dev}

---

Salut stephane92400

la methode que t'appele avec beforePhase doit avoir pour signature :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public void tamethode (PhaseEvent event){ // on récupère le context FacesContext context = event.getFacesContext(); //on récupère ton parametre HttpServletRequest request = (HttpServletRequest) context.getExternalContext().getRequest(); String indice = request.getParameter("indice"); // initialiser ton bean avec ce parametre en créant une value expression ValueExpression ve = context.getApplication().getExpressionFactory().createValueExpression(context.getELContext(),"#{tonbean}", java.lang.Object.class); Object tonbean = new Object(indice); //par exemple //affectation à la value expression ve.setValue(context.getELContext(),tonbean); }

---

voila

Pour pointer le bean ?

C'est dans ton managed bean JSF tout simplement.
exemple :
<t:saveState value="#{testRepartitionAgence.irisFiltre}" />


testRepartitionAgence est un managed bean JSF
irisFiltre est une valeur privée avec un getter et setter public...


Pour Medii : je pense pas qu'un phase listener soit nécessaire lorsque on peut faire un simple lazy loading du paramètre ....

qu'entends tu par lazy loading du paramètre heid?

J'entend faire ce que je t'explique dans les posts précédent :

A la première demande de la valeur, tu charges la valeur, ensuite tu te contentes de renvoyer cette valeur a chaque demande. Le save state te permet de conserver cette donnée dans le scope page.

Lazy loading = charement paresseux ou chargement à la demande.

Bonjour,
Remarques que ta méthode heid n'est pas vraiment tout ce qu'il y'a de plus propre et fiable ... je l'ai appris à mes dépens en passant deux heures de débogage et 100 lignes log.debug (log4j).
Ca venait du composant dataTable de RichFaces: j'ai fait le lazy loading de la liste d'objets dans le getter attaché à l'attribut value du dataTable. Dans ce getter, je calcule entre autre les sommes des colonnes que j'affiches dans le footer de la table.
Eh bien il s'est avéré que Richfaces dans toute sa sagesse a décidé qu'il commence par traiter le footer avant même d'appeler le getter du value, et donc j'obtenais le mauvais résultat dans le footer.

Bref, on n'est pas assuré de l'ordre dans lequel les composants sont rendered (y'as pas un equivalent français pour rendered ?) non plus sur l'ordre d'appele des getters.

Legen ............. dary :mouarf:

La tu ajoutes dans ton getter du métier alors que tu es dans le couche présen .... wait 4 it .....tation ;)

Pourquoi pas un DTO qui te retourne 1- la liste 2- les données connexes.

J'utilise cette méthode (pattern?) depuis 4 ans en <axe du mal> asp.net </axe du mal> depuis 6 moi en JSF j'ai pas eu un problème.

Citation:

---

Envoyé par heid

La tu ajoutes dans ton getter du métier alors que tu es dans le couche présen .... wait 4 it .....tation ;)

---

Euh ... non, le getter ne fait qu'appeléer la couche métier pour récupérer une liste de données, puis met à jour les totaux en conséquence (qui n'a rien à voir avec le métier).
Je ne croies pas que des calculs annexes de la sorte doivent être délégués ailleurs, car ils font strictement partie de la couche présentation/contrôle, c'est pour cela que je n'ai pas envisagé de passer par des DTOs.

j'ai remarqué que souvent JSF appelait plusieurs fois les getters d'un attribut, ta solution heid ne peut être efficace que pour certains cas mais dans une application bien plus complexe je doute qu'elle soit la plus optimale

Citation:

---

écrit par djo.mos
(y'as pas un equivalent français pour rendered ?)

---

le seul équivalent que j'ai trouvé c'est le rendu de composant

Citation:

---

Envoyé par Mediii

j'ai remarqué que souvent JSF appelait plusieurs fois les getters d'un attribut, ta solution heid ne peut être efficace que pour certains cas mais dans une application bien plus complexe je doute qu'elle soit la plus optimale

---

Ce que heid veut dire, c'est faire quelque chose comme ça :

Code:

---

1 2 3 4 5 6 7

public XXX getMonAttribut() { if (monAttribut == null) { // Trucs à faire pour initialiser monAttribut } return monAttribut; }

---

Donc même si le getter est appelé 10 fois, tu ne feras qu'une seule fois - au plus - appel au code d'initialisation de l'attribut...

romaintaz oui en effet en ajoutant ce if ça ne pose plus de problème

essaie de voir ca :http://jsf-comp.sourceforge.net/comp...oad/index.html
c'est si simple a mettre en ouvre et meme a modifer une seule classe (un phase listner)

Je trouve pas ça terrible, tu ajoutes un fichier de config et tu exporte ta logique de fonctionnement de ta page en dehors des fichier de ta page.
Personnellement je préfère utiliser un lazy loading pour initialiser des valeurs.
Par contre leur composant easy SI est terriblement utile.

Comment faire ca c'est simple je t'accorde ca mais pourquoi refaire quelque chose de deja fais ;)
mais quand tu parle de lazy loading ca veux dire quoi????

Lazy loading, ça veut dire qu'on ne charge / initialise une donnée que si on en a besoin, et non par défaut.
Le code suivant :

Code:

---

1 2 3 4 5 6 7

public Object getMyProperty() { if (myProperty == null) { // Initialisation de myProperty ... } return myProperty; }

---

est un exemple de Lazy Loading: On n'initialise myProperty que si on y fait appel...

Citation:

---

Envoyé par heid

Par contre leur composant easy SI est terriblement utile.

---

C'est pas une copie conforme de celui de tomahawk ?

Lequel? car je pense pas que le sioux nous permette de faire ce genre de truc : générer à la volée une liste de beans quelconque en SelectItem.

Moi ça me fait plutôt penser à l'approche asp.net ou les dropdownlists ont une propriété value et une propriété text.

Bah le <t:selectItems> ...

Amusant je n'avais jamais remarqué.
Merci pour l'info ;)