JSF f: l'événement preRenderView est déclenché par les appels f: ajax et les rendus partiels, autre chose?

Question

Nous avons donc un f: l'événement:

<f:metadata> 
    <f:event type="preRenderView" listener="#{dashboardBacking.loadProjectListFromDB}"/> 
    </f:metadata> 

qui est déclenché comme on le souhaite sur la charge de la page initiale (render).

Cependant, cet événement preRenderView est également déclenché par un rendu de page partiel ajax, qui rend un h: panelgroup avec l'ID projectListing, comme ci-dessous.

<h:commandButton action="#{mrBean.addProject}" value="Create Project" 
            title="Start a new project"> 
    <f:ajax render="projectListing" /> 
</h:commandButton> 

Je veux que le dashboardBacking.loadProjectListFromDB à appeler pour la première page rendu, mais pas quand il y a un ajax render partiel. Y a-t-il un événement ou une méthode plus approprié que je pourrais utiliser?

Answer 1

Une autre option consisterait à mettre votre fonctionnalité preRenderView dans une méthode @PostConstruct d'un bean géré ViewScoped. Cette logique serait exécutée lorsque le bean est initialisé, et vous maintenez la même instance du bean pour toutes vos requêtes ajax jusqu'à ce que vous changiez de vue.

Answer 2

Vous pouvez essayer d'attacher l'écouteur d'événement preRenderView à un composant individuel plutôt qu'à la page. Choisissez un composant qui n'est pas rendu lors d'une requête Ajax.

Answer 3

Une autre possibilité consiste à vérifier si la requête est ajax ou non dans la méthode preRenderView. Vous pouvez également effectuer la charge en tenant compte d'autres facteurs tels que si la requête est un GET ou non et si la validation a échoué ou non (la validation des paramètres d'affichage peut échouer sur la page GET).

boolean getMethod = ((HttpServletRequest) fc.getExternalContext().getRequest()).getMethod().equals("GET") ? true : false; 
boolean ajaxRequest = fc.getPartialViewContext().isAjaxRequest(); 
boolean validationFailed = fc.isValidationFailed(); 

Answer 4

Un petit problème est que les paramètres d'affichage ne sont pas réglées lorsque la méthode @PostConstruct est appelée donc je devais les faire explicitement:

FacesContext.getCurrentInstance().getExternalContext().getRequestParameterMap().get("theParam"); 

Answer 5

J'ai eu le même besoin pas trop longtemps . J'ai fini par utiliser quelque chose suggéré par BalusC.

Il y a une méthode dans la classe FacesContext qui vous permet de savoir si vous avez affaire à une demande complète soufflée ou un traitement partiel de quelque sorte:

FacesContext.getCurrentInstance().isPostback() 

De cette façon, vous pouvez toujours utiliser la technique preRenderView et vérifiez s'il s'agit d'une publication dans l'écouteur. J'ai trouvé cela particulièrement utile parce que j'avais besoin d'un bean de session car l'utilisateur devait naviguer vers une autre page et revenir. Si j'utilisais des haricots à vue (comme suggéré ci-dessus par Brian), je perdrais l'information que j'avais avant de partir.

Answer 6

Le "new-age" façon de gérer cela est décrit ici:

http://www.coderanch.com/t/509746/JSF/java/duplicate-call-preRenderView-event#2634752

Answer 7

mise à jour: En fait, je fini par faire la chose @PostConstruct, son plus propre.

J'ai eu exactement le même problème aujourd'hui avec un bean backing de portée session. À savoir, j'avais enregistré une méthode d'écouteur d'événements sur le bean de portée de session de sauvegarde qui était enregistré avec preRenderView. Mais j'ai constaté qu'il était également déclenché sur certaines opérations de tri Ajax sur un composant dataTable PrimeFaces 3.Donc, ce que j'ai fini par faire était d'utiliser une variable d'instance booléenne sur le bean support de session pour vérifier que le corps de la méthode event-listener n'était exécuté que la première fois (le booléen agissait comme un drapeau). Je suis sûr que c'est plutôt naïf et probablement cassé sur certains cas, donc je serais intéressé de savoir pourquoi et comment cette approche simpliste pourrait échouer.