jsf - form - process= @this primefaces

Comprender el proceso/actualización PrimeFaces y los atributos JSF f: ajax execute/render

Question

¿Qué es exactamente el process y la update en los componentes de PrimeFaces p:commandXxx y execute y render en la etiqueta f:ajax ?

¿Qué funciona en el momento de la validación? ¿Qué hace el atributo de update lugar de actualizar el valor del componente desde el back-end? ¿Procesar el valor del enlace de atributo al modelo? ¿Qué hacen exactamente @this , @parent , @all y @form en ambos atributos?

El siguiente ejemplo funciona bien, pero estoy un poco confundido en conceptos básicos.

<p:commandButton process="@parent"
                 update="@form"
                 action="#{bean.submit}" 
                 value="Submit" />

Answer 1

<p:commandXxx process> <p:ajax process> <f:ajax execute>

El atributo de process es del lado del servidor y solo puede afectar a UIComponent s implementando EditableValueHolder (campos de entrada) o ActionSource (campos de comando). El atributo de process le dice a JSF, utilizando una lista de ID de cliente separada por espacios, qué componentes deben procesarse exactamente a lo largo de todo el ciclo de vida de JSF al enviar formularios (parciales).

JSF aplicará los valores de solicitud (encontrando el parámetro de solicitud HTTP basado en el propio ID de cliente del componente y luego configurándolo como valor presentado en caso de componentes EditableValueHolder o haciendo cola en un nuevo ActionEvent en el caso de componentes de ActionSource ), realizará la conversión, validación y actualización del valores de modelo (solo componentes EditableValueHolder ) y finalmente invocar el ActionEvent cola ( ActionSource componentes de ActionSource ). JSF omitirá el procesamiento de todos los demás componentes que no están cubiertos por el atributo de process . Además, los componentes cuyo atributo rendered evalúa como false durante la fase de aplicar los valores de solicitud también se omitirán como parte de la protección contra las solicitudes manipuladas.

Tenga en cuenta que es en el caso de los componentes de ActionSource (como <p:commandButton> ) muy importante que también incluya el componente en el atributo de process , particularmente si tiene la intención de invocar la acción asociada con el componente. Por lo tanto, el siguiente ejemplo que intenta procesar solo ciertos componentes de entrada cuando se invoca un determinado componente de comando no funcionará:

<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="foo" action="#{bean.action}" />

Solo procesaría el #{bean.foo} y no el #{bean.action} . También necesitaría incluir el componente de comando:

<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="@this foo" action="#{bean.action}" />

O, como aparentemente descubrió, utilizando @parent si resultan ser los únicos componentes que tienen un elemento primario común:

<p:panel><!-- Type doesn''t matter, as long as it''s a common parent. -->
    <p:inputText id="foo" value="#{bean.foo}" />
    <p:commandButton process="@parent" action="#{bean.action}" />
</p:panel>

O bien, si ambos son los únicos componentes del componente UIForm principal, también puede usar @form :

<h:form>
    <p:inputText id="foo" value="#{bean.foo}" />
    <p:commandButton process="@form" action="#{bean.action}" />
</h:form>

Esto a veces es indeseable si el formulario contiene más componentes de entrada que le gustaría omitir en el procesamiento, más que a menudo en los casos en que desea actualizar otro (s) componente (s) de entrada o alguna sección de UI basada en el componente de entrada actual en un método de escucha ajax. Usted no quiere que los errores de validación en otros componentes de entrada impidan la ejecución del método de escucha ajax.

Luego está @all . Esto no tiene ningún efecto especial en el atributo de process , sino solo en el atributo de update . Un process="@all" comporta exactamente igual que process="@form" . HTML no admite el envío de formularios múltiples a la vez de todos modos.

Por cierto, también hay un @none que puede ser útil en caso de que no sea necesario procesar nada, pero solo desea actualizar algunas partes específicas a través de la update , especialmente aquellas secciones cuyo contenido no depende de los valores enviados o los oyentes de acción. .

El JSF estándar equivalente al process específico PrimeFaces se execute desde <f:ajax execute> . Se comporta exactamente de la misma manera, excepto que no admite una cadena separada por comas, mientras que la de PrimeFaces sí (aunque yo personalmente recomiendo que se adhiera a la convención separada por espacios), ni la palabra clave @parent . Además, puede ser útil saber que <p:commandXxx process> predeterminada en @form mientras que <p:ajax process> y <f:ajax execute> predeterminada en @this . Finalmente, también es útil saber que el process admite los llamados "selectores PrimeFaces", consulte también ¿Cómo funcionan los selectores PrimeFaces en update = "@ (. MyClass)"?

<p:commandXxx update> <p:ajax update> <f:ajax render>

El atributo de update es del lado del cliente y puede afectar la representación HTML de todos los UIComponent . El atributo de update le dice a JavaScript (el responsable del manejo de la solicitud / respuesta de ajax), utilizando una lista de ID de cliente separada por espacios, qué partes del árbol de DOM de HTML deben actualizarse como respuesta al envío de formularios.

JSF preparará entonces la respuesta ajax correcta para eso, que contiene solo las partes solicitadas para actualizar. JSF omitirá todos los demás componentes que no están cubiertos por el atributo de update en la respuesta de ajax, manteniendo así la carga de respuesta pequeña. Además, los componentes cuyo atributo rendered evalúa como false durante la fase de respuesta del renderizado serán omitidos. Tenga en cuenta que aunque devolvería true , JavaScript no puede actualizarlo en el árbol DOM HTML si inicialmente era false . Tendría que envolverlo o actualizar su padre en su lugar. Ver también Ajax update / render no funciona en un componente que tiene atributo renderizado .

Por lo general, le gustaría actualizar solo los componentes que realmente necesitan ser "actualizados" en el lado del cliente al enviar el formulario (parcial). El siguiente ejemplo actualiza el formulario principal completo a través de @form :

<h:form>
    <p:inputText id="foo" value="#{bean.foo}" required="true" />
    <p:message id="foo_m" for="foo" />
    <p:inputText id="bar" value="#{bean.bar}" required="true" />
    <p:message id="bar_m" for="bar" />
    <p:commandButton action="#{bean.action}" update="@form" />
</h:form>

(tenga en cuenta que el atributo de process se omite ya que predeterminado es @form )

Mientras que eso puede funcionar bien, la actualización de los componentes de entrada y comando es innecesaria en este ejemplo particular. A menos que cambie los valores del modelo foo y bar dentro del método de action (que a su vez no sería intuitivo en la perspectiva de UX), no tiene sentido actualizarlos. Los componentes del mensaje son los únicos que realmente necesitan actualizarse:

<h:form>
    <p:inputText id="foo" value="#{bean.foo}" required="true" />
    <p:message id="foo_m" for="foo" />
    <p:inputText id="bar" value="#{bean.bar}" required="true" />
    <p:message id="bar_m" for="bar" />
    <p:commandButton action="#{bean.action}" update="foo_m bar_m" />
</h:form>

Sin embargo, eso se vuelve tedioso cuando tienes muchos de ellos. Esa es una de las razones por las que existen PrimeFaces Selectors. Esos componentes del mensaje tienen en el código HTML generado una clase de estilo común de ui-message , por lo que lo siguiente también debería:

<h:form>
    <p:inputText id="foo" value="#{bean.foo}" required="true" />
    <p:message id="foo_m" for="foo" />
    <p:inputText id="bar" value="#{bean.bar}" required="true" />
    <p:message id="bar_m" for="bar" />
    <p:commandButton action="#{bean.action}" update="@(.ui-message)" />
</h:form>

(Tenga en cuenta que debe conservar los ID en los componentes del mensaje, de lo contrario, @(...) no funcionará. De nuevo, consulte ¿Cómo funcionan los selectores de PrimeFaces en update = "@ (. myClass)" para obtener más detalles ?

El @parent actualiza solo el componente padre, que cubre el componente actual y todos los hermanos y sus hijos. Esto es más útil si ha separado el formulario en grupos sanos con cada uno su propia responsabilidad. El @this actualiza, obviamente, solo el componente actual. Normalmente, esto solo es necesario cuando necesita cambiar uno de los atributos de HTML del componente en el método de acción. P.ej

<p:commandButton action="#{bean.action}" update="@this" 
    oncomplete="doSomething(''#{bean.value}'')" />

Imagine que el oncomplete necesita trabajar con el value que se cambia en action , entonces este constructo no habría funcionado si el componente no se actualiza, por la simple razón de que oncomplete es parte del resultado HTML generado (y por lo tanto todas las expresiones EL allí se evalúan durante la respuesta de renderizado).

El @all actualiza todo el documento, que debe usarse con cuidado. Normalmente, le gustaría usar una verdadera solicitud GET para esto en su lugar mediante un enlace simple ( <a> o <h:link> ) o una redirección-después-POST por ?faces-redirect=true o ExternalContext#redirect() En efectos, process="@form" update="@all" tiene exactamente el mismo efecto que un submit no-ajax (no parcial). En toda mi carrera en JSF, el único caso de uso sensato que encontré para @all es mostrar una página de error en su totalidad en caso de que ocurra una excepción durante una solicitud de Ajax. Consulte también ¿Cuál es la forma correcta de lidiar con las excepciones JSF 2.0 para componentes AJAXified?

El JSF estándar equivalente a la update específica PrimeFaces es render desde <f:ajax render> . Se comporta exactamente de la misma manera, excepto que no admite una cadena separada por comas, mientras que la de PrimeFaces sí (aunque yo personalmente recomiendo que se adhiera a la convención separada por espacios), ni la palabra clave @parent . Tanto la update como la render predeterminada son @none (que es, "nada").

Ver también:

• ¿Cómo averiguar la identificación del cliente del componente para la actualización / renderización de Ajax? No se puede encontrar el componente con la expresión "foo" a la que se hace referencia desde "barra"
• Orden de ejecución de eventos al presionar PrimeFaces p: commandButton
• Cómo disminuir la carga de solicitud de p: ajax durante, por ejemplo, la paginación p: datatable
• Cómo mostrar detalles de la fila actual desde p: dataTable en ap: diálogo y actualizar después de guardar
• ¿Cómo se usa <h: form> en la página JSF? ¿Forma única? Múltiples formas? Formas anidadas?

Answer 2

Por proceso (en la especificación JSF se llama ejecutar) le dices a JSF que limite el procesamiento al componente y que todo lo demás se ignore.

la actualización indica qué elemento se actualizará cuando el servidor responda a su solicitud.

@all : cada componente se procesa / procesa.

@this : el componente solicitante con el atributo de ejecución se procesa / procesa.

@form : el formulario que contiene el componente solicitante se procesa / procesa.

@parent : el padre que contiene el componente solicitante se procesa / procesa.

Con Primefaces puedes incluso usar los selectores de JQuery, mira este blog: http://blog.primefaces.org/?p=1867

Answer 3

Si le resulta difícil recordar los valores predeterminados (sé que tengo ...) aquí hay un breve extracto de la respuesta de BalusC:

Component | Submit | Refresh ------------ | --------------- | -------------- f:ajax | execute="@this" | render="@none" p:ajax | process="@this" | update="@none" p:commandXXX | process="@form" | update="@none"