commandButton/commandLink/acción ajax/oyente método no se invoca o valor de entrada no se establece/actualizado

A veces, cuando se utiliza <h:commandLink>, <h:commandButton> o <f:ajax>, el action, actionListener o listener método asociado con la etiqueta sencillamente, no se invoca. O, el frijol propiedades no se actualizan con la presentada UIInput valores.

¿Cuáles son las posibles causas y soluciones para esto?

OriginalEl autor Muhammad Hewedy | 2010-01-22

9 Kommentare

  1. 645

    Introducción

    Siempre que un UICommand componente (<h:commandXxx>, <p:commandXxx>, etc) no se puede invocar la acción asociada método, o una UIInput componente (<h:inputXxx>, <p:inputXxxx>, etc) no puede procesar los valores enviados y/o actualizar los valores del modelo, y que usted no está viendo ningún googlable excepciones y/o advertencias en el registro del servidor, también no al configurar un ajax controlador de excepciones como por Manejo de excepciones en JSF peticiones ajax, ni cuando se establece a continuación parámetro de contexto en web.xml,

    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
    </context-param>

    y no ver ningún googlable errores y/o advertencias en el navegador de la consola de JavaScript (presione F12 en Chrome/Firefox23+/IE9+ para abrir la web de desarrolladores de herramientas y, a continuación, abra el Consola ficha) y, luego, a continuación de la lista de posibles causas.

    Posibles causas

    1. UICommand y UIInput componentes debe ser colocado dentro de un UIForm componente, por ejemplo, <h:form> (y por lo tanto no HTML <form>), de lo contrario, nada puede ser enviado al servidor. UICommand componentes no debe también han type="button" atributo, de lo contrario será un botón muerto que sólo es útil para JavaScript onclick. Véase también Cómo enviar el formulario de valores de entrada y la invocación de un método en JSF bean y <h:commandButton> no iniciar una devolución de datos.

    2. No se pueden anidar varias UIForm componentes en cada uno de los otros. Esto es ilegal en HTML. El comportamiento del navegador no está especificado. Cuidado con incluir archivos! Usted puede utilizar UIForm componentes en paralelo, pero no el proceso de cada uno de los otros durante presentar. Usted también debe mirar hacia fuera con «Forma de Dios» antipattern; asegúrese de que usted no involuntariamente proceso/validar todos los demás (invisible) entradas en la misma forma (por ejemplo, tener un diálogo oculto con los insumos necesarios en la misma forma). Véase también Cómo utilizar <h:form> en JSF página? Solo formulario? Múltiples formas? Los formularios anidados?.

    3. No UIInput valor de validación/error de conversión debería haber ocurrido. Usted puede utilizar <h:messages> para mostrar los mensajes que no se muestran por cualquier entrada específica <h:message> componentes. No olvides incluir el id de <h:messages> en el <f:ajax render>, si alguno, de modo que éste se encuentre actualizado, así como en peticiones ajax. Véase también h:los mensajes no muestra mensajes cuando p:commandButton se pulsa.

    4. Si UICommand o UIInput componentes se colocan dentro de una iteración componente, como <h:dataTable>, <ui:repeat>, etc, entonces usted necesita para asegurarse de que exactamente el mismo value de la iteración componente se ha conservado durante la aplicación de solicitud de los valores de la fase de la forma de envío de solicitud. JSF se reitera sobre ella para encontrar el enlace pulsado el botón/y presentaron valores de entrada. Poner las alubias a la vista del alcance y/o asegurarse de que se carga el modelo de datos en @PostConstruct de la haba (y, por tanto, no en un método getter!) debería solucionar el problema. Véase también ¿Cómo y cuándo debo cargar el modelo de base de datos para h:dataTable.

    5. Si UICommand o UIInput de los componentes está incluido en una fuente dinámica como <ui:include src="#{bean.include}">, entonces usted necesita para asegurarse de que exactamente el mismo #{bean.include} valor se conserva durante la vista en el momento de la compilación del formulario de envío de solicitud. JSF va a ejecutar de nuevo durante la construcción del árbol de componentes. Poner las alubias a la vista del alcance y/o asegurarse de que se carga el modelo de datos en @PostConstruct de la haba (y, por tanto, no en un método getter!) debería solucionar el problema. Véase también Cómo ajax-actualización dinámica de incluir contenido menú de navegación? (JSF SPA).

    6. La rendered atributo del componente y todos sus padres y la test atributo de cualquier padre <c:if>/<c:when> no debe evaluar a false durante la aplicación de solicitud de los valores de la fase de la forma de envío de solicitud. JSF se vuelve a revisar como parte de salvaguardia contra alterado/hackeado solicitudes. El almacenamiento de las variables responsables de la condición en un @ViewScoped bean o asegurarse de que usted está adecuadamente preinitializing la condición en @PostConstruct de un @RequestScoped bean debería solucionar el problema. Lo mismo se aplica a la disabled atributo del componente, que no se debería evaluar a true durante aplicar solicitud de los valores de fase. Véase también JSF CommandButton acción no se invoca y Presentar en forma condicional prestados componente no está procesado.

    7. La onclick atributo de la UICommand componente y el onsubmit atributo de la UIForm componente no debe volver false o causar un error de JavaScript. No debería, en caso de <h:commandLink> o <f:ajax> también no JS errores visibles en el navegador del JS console. Generalmente googlear el mensaje de error exacto ya te da la respuesta. Véase también La adición de jQuery para PrimeFaces resultados en Uncaught TypeError sobre todo el lugar.

    8. Si usted está usando Ajax a través de JSF 2.x <f:ajax> o, por ejemplo, PrimeFaces <p:commandXxx>, asegúrese de que usted tiene un <h:head> en la plantilla maestra en lugar de la <head>. De lo contrario, JSF no ser capaz de auto-incluir la necesaria archivos JavaScript que contiene las funciones Ajax. Esto daría como resultado un error de JavaScript como «mojarra no está definida» o «PrimeFaces no está definido» en el navegador del JS console. Véase también h:commandLink actionlistener no se invoca cuando se utiliza con f:ajax y ui:repeat.

    9. Si usted está usando Ajax, a continuación, asegúrese de que el UIInput y UICommand componentes de interés son cubiertos por el <f:ajax execute> o, por ejemplo,<p:commandXxx process>, de lo contrario no será ejecutado/procesado. Véase también Formulario enviado valores no se actualizan en el modelo al añadir <f:ajax> <h:commandButton> y La comprensión de PrimeFaces y proceso de actualización y JSF f:ajax ejecutar y representar los atributos.

    10. Si el padre de la <h:form> con el UICommand botón de antemano sido prestados/actualizado mediante una petición ajax viene de otro formulario en la misma página, la primera acción siempre se producirá un error. En la segunda y subsiguientes acciones de trabajo. Esto es causado por un error en el estado de vista de la manipulación que se ha reportado como JSF spec problema 790 y, actualmente programado para ser fijado en JSF 2.3. Para mayores JSF versiones, deberá especificar explícitamente el ID de la <h:form> en el render de la <f:ajax>. Véase también h:commandButton/h:commandLink no funciona en el primer clic, sólo funciona en segundo clic.

    11. Si el <h:form> ha enctype="multipart/form-data" en el fin de archivo de soporte de carga, entonces usted necesita para asegurarse de que usted está utilizando, al menos, JSF 2.2, o que el filtro de servlets que es responsable para el análisis de multipart/form-las solicitudes de datos está configurado correctamente, de lo contrario el FacesServlet va a terminar ninguna solicitud de los parámetros de todos y, por tanto, no ser capaz de aplicar la solicitud de los valores. Cómo configurar un filtro depende de la carga de archivos de componente que se utiliza. Para Tomahawk <t:inputFileUpload>, compruebe esta respuesta y para PrimeFaces <p:fileUpload>, compruebe esta respuesta. O, si usted es realmente de no subir un archivo a todos, a continuación, quite el atributo por completo.

    12. Asegúrese de que el ActionEvent argumento de actionListener es un javax.faces.event.ActionEvent y por lo tanto no java.awt.event.ActionEvent, que es lo que la mayoría de los IDEs sugieren como 1ª opción de autocompletar. No tener argumento es erróneo, así si se utiliza actionListener="#{bean.method}". Si no quieres un argumento en su método, el uso de actionListener="#{bean.method()}". O tal vez usted realmente desea utilizar action en lugar de actionListener. Véase también Las diferencias entre la acción y el actionListener.

    13. Asegúrese de que no hay PhaseListener o cualquier EventListener en la solicitud-respuesta de la cadena ha cambiado el ciclo de vida de JSF para saltar al invocar la fase de acción, por ejemplo, llamar a FacesContext#renderResponse() o FacesContext#responseComplete().

    14. Asegúrese de que no hay Filter o Servlet en la misma solicitud-respuesta de la cadena ha bloqueado la solicitud de las fo de la FacesServlet de alguna manera.

    15. Error en el marco. Por ejemplo, RichFaces tiene un «error de conversión» cuando se utiliza un rich:calendar elemento de interfaz de usuario con un defaultLabel atributo (o, en algunos casos, un rich:placeholder sub-elemento). Este error impide que el bean método se invoca cuando no se establece ningún valor para la fecha del calendario. Marco de seguimiento de errores puede realizarse comenzando con un simple ejemplo de trabajo y la creación de la página copia de seguridad hasta que el error es descubierto.

    16. Si usted está usando un PrimeFaces p:dialog o un p:overlayPanel, asegúrese de que usted no se quede en p:commandbutton acción no funciona en el interior de p:diálogo

    La depuración de las sugerencias de

    En caso de que aún stucks, es hora de depurar. En el lado del cliente, pulse F12 en webbrowser para abrir la web de desarrolladores un conjunto de herramientas. Haga clic en el Consola pestaña para ver el JavaScript conosle. Debe estar libre de errores de JavaScript. La siguiente captura de pantalla es un ejemplo de Chrome, el cual demuestra el caso de la presentación de una <f:ajax> habilitado un botón, mientras que no tener <h:head> declarado (como se describe en el punto 7).

    commandButton/commandLink/acción ajax/oyente método no se invoca o valor de entrada no se establece/actualizado

    Haga clic en el Red tab para ver el tráfico HTTP monitor. Enviar el formulario e investigar si los encabezados de solicitud y formulario de datos y el cuerpo de la respuesta son como por las expectativas. La siguiente captura de pantalla es un ejemplo de Chrome, que demuestra un éxito ajax presentar de una forma sencilla con una sola <h:inputText> y una sola <h:commandButton> con <f:ajax execute="@form" render="@form">.

    commandButton/commandLink/acción ajax/oyente método no se invoca o valor de entrada no se establece/actualizado

    (advertencia: al publicar capturas de pantalla de los encabezados de solicitud HTTP, como por encima de un entorno de producción, a continuación, asegúrese de que usted scramble/ocultar cualquier cookies de sesión en la captura de pantalla para evitar ataques de secuestro de sesión!)

    En el lado del servidor, asegúrese de que el servidor se inicia en modo de depuración. Poner una depuración de punto de interrupción en un método de la JSF componente de interés que esperar a ser llamado durante el procesamiento, el formulario de envío. E. g. en caso de UICommand componente, que sería UICommand#queueEvent() y en caso de UIInput componente, que sería UIInput#validar(). Solo paso a través de la ejecución de código e inspeccione si el flujo y variables como por las expectativas. La siguiente captura de pantalla es un ejemplo de Eclipse del depurador.

    commandButton/commandLink/acción ajax/oyente método no se invoca o valor de entrada no se establece/actualizado

    2º punto que me hizo pensar, por un largo tiempo. Me acabo de enterar de que un f:ver etiqueta en mi archivo principal fue la causa de la mayoría de mis problemas. Y, probablemente, ya que representa una forma, ¿verdad?
    No puedo encontrar nada que los estados que f:vista muestra un formulario. Mi entendimiento es que es sólo un contenedor. En mi experiencia, f:vista de no hacer ningún tipo de elementos.
    Una pequeña aclaración sobre el punto 4, si el commandLink no está en la tabla de datos en sí, ¿aún le importa?
    gracias, el punto es el punto:Poner las alubias a la vista del alcance y/o asegurarse de que se carga el modelo de datos en el (post)constructor de la haba (y, por tanto, no en el método getter!) debería solucionar el problema.
    que habrían arrojado una luz de excepción (ya cubiertos por el párrafo 1 en la respuesta)

    OriginalEl autor BalusC

  2. 51

    Si su h:commandLink está dentro de un h:dataTable hay otra razón por la que el h:commandLink podría no funcionar:

    Subyacente de origen de datos vinculado a la h:dataTable también debe estar disponible en el segundo JSF-ciclo de vida que se activa cuando se hace clic en el enlace.

    Por lo que si los datos subyacentes-fuente es un ámbito de petición, el h:commandLink no funciona!

    Que ya está cubierto en el punto 4 de mi respuesta.
    Ok, que no estaba completamente claro para mí. Espero que mi respuesta es útil de todos modos, ya que en mi caso al menos, yo no estaba tratando explícitamente con UICommand/UIData. La «solución» fue la promoción de un backing bean de solicitud-ámbito el ámbito de la sesión …
    En la segunda Jens comentario…mi RequestScoped bean para ser SessionScoped hecho la diferencia en mi dataTable – gracias

    OriginalEl autor jbandi

  3. 25

    Mientras que mi respuesta no es 100% aplicable, pero la mayoría de los motores de búsqueda encontrar esta como el primer golpe, me decidí a publicar esto:

    Si usted está usando PrimeFaces (o alguna similar API) p:commandButton o p:commandLink, es probable que usted se haya olvidado de agregar explícitamente process="@this" a su comando de componentes.

    Como PrimeFaces Guía del Usuario de los estados en la sección 3.18, los valores predeterminados para process y update son tanto @form, que casi se opone a los valores predeterminados que se puede esperar de la llanura JSF f:ajax o RichFaces, que son execute="@this" y render="@none" respectivamente.

    Sólo me llevó muchísimo tiempo para averiguarlo. (… y creo que es de bastante unclever para utilizar los valores predeterminados que son diferentes de JSF!)

    El valor predeterminado para PrimeFaces process es @form. De modo que si la acción no es invocado de esta manera, pero cuando se utiliza @this, entonces lo más probable es que el punto 3 de mi respuesta se aplica.
    Esto no puede ser. Yo tenía un p:commandButton que no invocar el actionListener método hasta que he añadido process="@this". Además, el PrimeFaces Guía del Usuario se incluye explícitamente los valores predeterminados he mencionado en la sección 3.18 y 3.19. Está aquí: primefaces.googlecode.com/files/primefaces_users_guide_3_4.pdf … tal vez los valores predeterminados se han cambiado?
    Es probable que un error en la documentación. Quitar process="@this" y agregar <p:messages autoUpdate="true"> (o simplemente leer servidor de registro en cola, pero no mostrado mensajes) y verás que, en realidad, una conversión a/validación se ha producido un error.

    OriginalEl autor Kawu

  4. 9

    Me gustaría mencionar una cosa más que preocupaciones Primefaces del p:commandButton!

    Cuando se utiliza un p:commandButton para la acción que debe realizarse en el servidor, no se puede utilizar type="button" porque eso es para botones, que se utiliza para ejecutar javascript personalizado sin causar un ajax/no-petición ajax al servidor.

    Para este propósito, se puede prescindir de la type atributo (el valor predeterminado es "submit") o puede utilizar explícitamente type="submit".

    Espero que esto ayude a alguien!

    este fue mi principal problema en una de nuestras páginas, ninguno de los puntos en los aceptadas respuesta nos acercan, ¿dónde se encuentra esta información?
    Bueno, yo he tenido ese problema, muchas veces, y me hizo una investigación y encontrar que p:commandButton tiene varios valores de type atributo, y button es que se refiere a todo lo que sobre el lado del cliente. Es un poco difícil de encontrar esto en Primefaces doc, pero aquí hay un enlace: desarrollador.am/primefaces/…
    Presentar sugerencia resuelto mi problema he estado enfrentando durante días. Muchas gracias por tu post!
    Gracias, es mi placer. Yo deliberadamente poner esta respuesta porque muchos de nosotros tuvimos un problema. Yo había perdido un par de días hasta que se dio cuenta de lo que se trata.

    OriginalEl autor akelec

  5. 3

    Recientemente me encontré con un problema con un UICommand no invocar en un JSF 1.2 aplicación que utiliza IBM Extendido Caras Componentes.

    Yo tenía un botón de comando en una fila de una tabla de datos (la versión extendida, por lo que <hx:datatable>) y el UICommand no el fuego de ciertas filas de la tabla (las filas que no el fuego fueron las filas mayor que el valor predeterminado de la fila de tamaño de la pantalla).

    Tuve un desplegable componente para seleccionar el número de filas a mostrar. El valor de la copia de este campo fue en RequestScope. Los datos de copia de la tabla en sí estaba en una especie de ViewScope (en realidad, temporalmente en SessionScope).

    Si la fila de la pantalla se incrementó a través del control de valor de la cual también fue enlazado a la tabla de datos del rows atributo, ninguna de las filas que aparecen como resultado de este cambio podría disparar la UICommand cuando se hace clic.

    La colocación de este atributo en el mismo ámbito de aplicación como los datos de la tabla en sí se ha solucionado el problema.

    Creo que este es aludido en BalusC #4 arriba, pero no sólo el valor de la tabla necesita ser Vista o un ámbito de Sesión, pero también el atributo de controlar el número de filas que se mostrarán en la tabla.

    OriginalEl autor Brent C

  6. 2

    Se quedó atascado con este tema a mí mismo y encontrar una de las causas más para este problema.
    Si usted no tiene métodos setter en tu copia de frijol para las propiedades que se utilizan en su *.xhtml , entonces la acción es simplemente no se invoca.

    Debe haber resultado en un lugar de auto-explicar PropertyNotWritableException. Si no lo veo, tal vez te despidan a una petición ajax sin un adecuado ajax controlador de excepciones, pero usted debe ver en los registros del servidor.
    No mostrar que la excepción hasta me hizo p:commandButton del ajax=»false».

    OriginalEl autor Syed Mehtab

  7. 2

    He tenido este problema así y empezaron a centrarse en la raíz de la causa después de abrir el navegador web de la consola. Hasta que, era incapaz de obtener los mensajes de error (incluso con <p:messages>). La consola web mostró un HTTP 405 código de estado de regresar de la <h:commandButton type="submit" action="#{myBean.submit}">.

    En mi caso, tengo una mezcla de vainilla HttpServlet proporciona autenticación OAuth a través de Auth0 y JSF facelets y frijoles llevar a cabo mis vistas de la aplicación y la lógica de negocio.

    Una vez me refactorizado mi web.xml y quitó un medio-hombre-servlet, a continuación, «por arte de magia» trabajado.

    Línea de fondo, el problema era que el medio-hombre-servlet estaba usando RequestDispatcher.hacia adelante(…) para redirigir a partir de la HttpServlet medio ambiente para el JSF medio ambiente mientras que el servlet ser llamado antes de la era de redireccionar con HttpServletResponse.sendRedirect(…).

    Básicamente, el uso de sendRedirect() permitió que el JSF «contenedor» para tomar el control mientras que RequestDispatcher.forward() fue, obviamente, no.

    Lo que no sé es por qué la facelet fue capaz de acceder a las propiedades del bean pero no se pudo establecer con ellos, y esto claramente gritos para acabar con la mezcla de servlets y JSF, pero espero que esto ayude a alguien a evitar muchas horas de cabeza a la mesa golpeando.

    OriginalEl autor Brooks

  8. 0

    Yo tenía un montón de diversión de depuración de un problema donde un <h:commandLink>‘s de acción en richfaces datatable negó a disparar. La tabla que se utiliza para trabajar en algún punto, pero se detuvo sin razón aparente. He dejado piedra sin remover, sólo para descubrir que mi rich:datatable fue la utilización incorrecta de rowKeyConverter que devuelven valores nulos que richfaces felizmente utilizado como fila de teclas. Esto impidió que mi <h:commandLink> acción de recibir llamadas.

    OriginalEl autor Mustafa

  9. 0

    Una posibilidad más: si el síntoma es que la primera invocación obras, pero las siguientes no, puede que esté utilizando PrimeFaces 3.x con JSF 2.2, como se detalla aquí: ViewState No se envía.

    OriginalEl autor Dave Mulligan

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Pruebas en línea