ajax - form - primefaces

JSF f: el evento preRenderView se desencadena con las llamadas f: ajax y los renders parciales, ¿algo más?

Question

Así que tenemos un evento f:

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

Que se dispara como se desea en la carga de la página inicial (render).

Sin embargo, este evento preRenderView también se desencadena mediante un procesamiento de página parcial ajax, que vuelve a representar un grupo h: panel con la lista de proyectos id, como se muestra a continuación.

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

Solo quiero que se llame al dashboardBacking.loadProjectListFromDB para el procesamiento de la página inicial, pero no cuando hay un procesamiento parcial de ajax. ¿Hay algún evento o método más apropiado que pueda estar usando?

Answer 1

La forma de "nueva era" de manejar esto se describe aquí:

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

Answer 2

Otra opción sería colocar su funcionalidad preRenderView en un método @PostConstruct de un ViewScoped administrado ViewScoped . Esta lógica se ejecutaría cuando el bean se inicialice, y usted mantiene la misma instancia del bean para todas sus solicitudes de ajax hasta que cambie las vistas.

Answer 3

Otra posibilidad es verificar si la solicitud es ajax o no en el método preRenderView. También puede realizar la carga de forma condicional considerando otros factores, como si la solicitud es un GET o no y si la validación falló o no (la validación de parámetros puede fallar en la página GET).

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

Answer 4

Puede intentar adjuntar el detector de eventos preRenderView a un componente individual, en lugar de a la página. Elija un componente que no se represente durante una solicitud Ajax.

Answer 5

Tuve la misma necesidad no hace mucho tiempo. Terminé usando algo sugerido por BalusC .

Hay un método en la clase FacesContext que le permite saber si está tratando con una solicitud completa o un procesamiento parcial de algún tipo:

FacesContext.getCurrentInstance().isPostback()

De esta manera, aún puede utilizar la técnica preRenderView y verificar si es una devolución de datos en el oyente. Lo encontré particularmente útil porque necesitaba un bean de sesión, ya que el usuario tenía que navegar a otra página y volver. Si usara frijoles de vista (como sugerido anteriormente por Brian), perdería la información que tenía antes de navegar.

Answer 6

Un pequeño problema es que los parámetros de vista no se han establecido cuando se llama al método @PostConstruct, así que tuve que obtenerlos explícitamente:

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

Answer 7

actualización : en realidad, terminé haciendo lo de @PostConstruct, es mucho más limpio.

Hoy tuve exactamente el mismo problema con un bean de respaldo de sesión. A saber, había registrado un método de escucha de eventos en el bean de ámbito de sesión de respaldo que estaba registrado con preRenderView. Pero descubrí que también se activó en algunas operaciones de clasificación Ajax en un componente de tabla de datos PrimeFaces 3. Entonces, lo que terminé haciendo fue usar una variable de instancia booleana en el bean de respaldo con sesión de sesión para asegurarme de que el cuerpo del método de escucha de eventos se ejecutó solo la primera vez (el booleano actuó como un indicador). Estoy seguro de que es bastante ingenuo y probablemente está roto en ciertos casos, por lo que me interesaría saber por qué y cómo este enfoque simplista podría fallar.