Hay gran cantidad de materiales diferenciar value atributo y binding atributo en JSF.

Estoy interesado en cómo ambos enfoques difieren de uno a otro. Dado:

public class User {
    private String name;
    private UICommand link;

    //Getters and setters omitted.
}
<h:form>
    <h:commandLink binding="#{user.link}" value="#{user.name}" />
</h:form>

Es muy sencillo lo que sucede cuando una value atributo se especifica. El captador de carreras para devolver el name valor de la propiedad de la User bean. El valor se imprime a la salida HTML.

Pero yo no podía entender cómo binding obras. ¿Cómo funciona el HTML generado mantener un enlace con el link propiedad de la User bean?

A continuación es la parte pertinente de la salida generada después de que el manual de embellecimiento y comentar (tenga en cuenta que el id de j_id_jsp_1847466274_1 se auto-generado y que hay dos oculto de entrada widgets).
Yo estoy usando la del Sol JSF RI, versión 1.2.

<form action="/TestJSF/main.jsf" enctype="application/x-www-form-urlencoded"
    id="j_id_jsp_1847466274_1" method="post"  name="j_id_jsp_1847466274_1">
    <input name="j_id_jsp_1847466274_1" type="hidden" value="j_id_jsp_1847466274_1">
    <a href="#" onclick="...">Name</a>
    <input autocomplete="off" id="javax.faces.ViewState" name="javax.faces.ViewState"
        type="hidden" value="-908991273579182886:-7278326187282654551">
</form>

Donde es el binding almacenados aquí?

OriginalEl autor John | 2013-02-16

2 Comentarios

  1. 111

    ¿Cómo funciona?

    Cuando una JSF vista (Facelets/archivo JSP) obtener construido y restaurado, un árbol de componentes JSF será producida. En ese momento, el ver el tiempo de construcción, todos binding los atributos evaluados (junto con id attribtues y taghandlers como JSTL). Cuando el JSF componente debe ser creado antes de ser agregado a el árbol de componentes JSF comprobará si el binding atributo devuelve una creada previamente componente (es decir, nonull) y si es así, entonces el uso de la misma. Si no es creada previamente, a continuación, JSF se autocreate el componente de «la manera habitual» e invocar el setter detrás de binding atributo con el autocreated instancia de componente como argumento.

    Efectos, se une una referencia de la instancia de componente en el árbol de componentes a un ámbito de la variable. Esta información es de ninguna manera visible en el código HTML generado representación del propio componente. Esta información es en absoluto relevante para generar el HTML de salida de todos modos. Cuando el formulario es enviado, y la vista es restaurado, el árbol de componentes JSF es reconstruido a partir de cero y todos los binding atributos acaba de ser re-evaluado como la descrita en el párrafo anterior. Después de que el árbol de componentes es recreado, JSF, se restaurará la JSF estado de vista en el árbol de componentes.

    Las instancias de los componentes son un ámbito de petición!

    Importante saber y entender que el hormigón de las instancias de los componentes son efectivamente ámbito de petición. Están recién creado en cada solicitud y sus propiedades están llenos de valores de JSF estado de la vista durante la restauración de la vista de fase. Por lo tanto, si usted enlazar el componente a una propiedad de un backing bean, entonces el respaldo de frijol debe absolutamente no estar en un ámbito más amplio que el ámbito de petición. Véase también JSF 2.0 specitication capítulo 3.1.5:

    3.1.5 Componente De Enlaces

    Componente de enlaces se utilizan a menudo en combinación con JavaBeans que son instancias dinámicas a través de los Administrados
    Bean Creación de la instalación (consulte la Sección 5.8.1 «VariableResolver y el Defecto VariableResolver»). Es muy
    recomendamos que los desarrolladores de aplicaciones lugar managed beans que son señaladas por componente expresiones de enlace en
    «petición» de alcance.
    Esto es debido a que la colocación de ella en la sesión o en el ámbito de la aplicación requeriría hilo de seguridad, ya que
    UIComponent instancias depende de que se ejecuta dentro de un solo hilo. También hay impactos potencialmente negativos sobre
    memoria de la administración a la hora de colocar un componente de unión en «sesión» ámbito de aplicación.

    De otra manera, las instancias de los componentes son compartidos entre varias solicitudes, resultando posiblemente en «duplicar IDENTIFICADOR de componente errores de» y «extraño» comportamiento debido a que los validadores, los convertidores y de los oyentes declarado en la vista se re-conectado con el componente existente instancia de la solicitud anterior(s). Los síntomas son claros: se ejecuta varias veces, una vez más con cada solicitud dentro del mismo ámbito como el componente está destinado a.

    Y, en condiciones de carga pesada (es decir, cuando varias peticiones HTTP (hilos) el acceso y manipulación de la misma instancia de componente en el mismo tiempo), puede enfrentarse tarde o temprano a un bloqueo de la aplicación, por ejemplo, con Atascado hilo en UIComponent.popComponentFromEL, o Las Hebras Java al 100% de la CPU utilizando richfaces UIDataAdaptorBase internos y sus HashMap, o incluso un poco «extraño» IndexOutOfBoundsException o ConcurrentModificationException que vienen directamente de JSF implementación de código fuente mientras que el JSF está ocupado en salvar o recuperar el estado de la vista (es decir, la traza de la pila indica saveState() o restoreState() métodos y similares).

    Utilizando binding en un bean de la propiedad es una mala práctica

    Independientemente, utilizando binding de esta manera, la unión de un conjunto de componentes instancia de un bean de la propiedad, incluso en un ámbito de petición de frijol, es en JSF 2.x un raro lugar de casos de uso y, en general, no es la mejor práctica. Esto indica que el diseño de olor. Normalmente declarar componentes en la vista de lado y se unen sus atributos en tiempo de ejecución como value, y tal vez otros como styleClass, disabled, rendered, etc, a la normalidad de frijol propiedades. Entonces, sólo tienes que manipular exactamente que bean propiedad que desea en lugar de arrastrar el componente entero y llamar al método setter asociado con el atributo.

    En los casos en que un componente debe ser «dinámica», basado en un modelo estático, lo mejor es utilizar ver el tiempo de construcción de las etiquetas como JSTL, si es necesario en un archivo de la etiqueta, en lugar de createComponent(), new SomeComponent(), getChildren().add() y lo que no. Véase también Cómo refactorizar fragmento de la vieja JSP para algunos JSF equivalente?

    O, si un componente tiene que ser «dinámicamente prestados», basado en un modelo dinámico, a continuación, sólo tiene que utilizar una iterador componente (<ui:repeat>, <h:dataTable>, etc). Véase también Cómo agregar dinámicamente componentes JSF.

    Componentes de material compuesto es una historia completamente diferente. Es completamente de fiar para enlazar componentes dentro de un <cc:implementation> a la copia de componente (es decir, el componente identificado por <cc:interface componentType>. Ver también.o. División de java.util.La fecha más de dos h:inputText campos en representación de la hora y los minutos con f:convertDateTime y Cómo implementar una lista dinámica con JSF 2.0 Componente Compuesto?

    Sólo uso binding en el ámbito local

    Sin embargo, a veces te gustaría saber sobre el estado de un componente diferente desde el interior de un componente en particular, más a menudo en los casos de uso relacionados con la acción/valor dependiente de la validación. Por eso, el binding atributo puede ser utilizado, pero no en combinación con un bean de la propiedad. Sólo se puede especificar una en el local de EL alcance único nombre de variable en la binding atributo como binding="#{foo}" y el componente durante el procesamiento de la respuesta en otros lugares en el mismo punto de vista directamente como UIComponent de referencia disponible por #{foo}. Aquí hay varias preguntas relacionadas cuando una solución se ha utilizado en la respuesta:

    Véase también:

    Me puse de usuario como ámbito de petición de frijol. Y trató de sysout en getlink y setlink métodos. Al aterrizar en la página = User.User(), User.getLink(), User.setLink(), User.getValue() Cuando hago clic en el enlace = User.User(), User.setLink()...
    ¿Por qué es setLink() llama una y otra UICommand objeto creado cuando se tiene uno ya?
    «si se unen […], entonces el respaldo de frijol no debe absolutamente ser en un ámbito más amplio que el ámbito de petición». Es cierto esto todavía en JSF 2.2? ¿Cuál es la mejor opción si tengo que programáticamente se incluyen los componentes en la página con getChildren().addAll(…)?
    El uso de JSTL para crear mediante programación la vista sólo en la sintaxis de XML.
    De hecho. UIViewRoot (todos de UIComponent básicamente) es unserializable de todos modos.

    OriginalEl autor BalusC

  2. 0

    cada componente JSF hace de sí mismo a HTML y tiene el control completo sobre lo que HTML se produce. Hay muchos trucos que pueden ser utilizados por JSF, y exactamente cual de esos trucos va a ser utilizado depende de la JSF aplicación que está utilizando.

    • Garantizar que todos los de la entrada tiene un totalmente único nombre, de modo que cuando el formulario sea enviado de vuelta a al árbol de componentes que se hizo, es fácil decir, donde cada componente puede leer su forma de valor.
    • El componente JSF puede generar javascript que submitts de vuelta a la serer, javascript generado sabe donde cada componente está vinculado también porque era generado por el componente.
    • Para cosas como hlink puede incluir la información de enlace en la url de la consulta de parámetros o como parte de la url en sí mismo o como matrx parámetros. para los ejemplos.

      http:..../somelink?componentId=123 permitiría jsf a buscar en el árbol de componentes para ver que link 123 se ha hecho clic. o podía e htp:..../jsf;LinkId=123

    La forma más sencilla de responder a esta pregunta es crear una página JSF con sólo un enlace, a continuación, examine el código html de salida que produce. De esa manera usted sabrá exactamente cómo sucede con la versión de JSF que usted está usando.

    Yo diría que solo he usado el componente de unión a la hora de generar el componente de forma dinámica en el lado del servidor, la configuración de todos los atributos como action y value, y luego dejar que el JSF marco de su trabajo.
    Yo almacenados user como el ámbito de la aplicación bean gestionado y cuando hago clic en el enlace de cada momento, sólo el segundo número en value="-908991273579182886:-7278326187282654551" cambios y todo lo demás es lo mismo. Pregunto lo de la magia de estos.

    OriginalEl autor ams

Dejar respuesta

Please enter your comment!
Please enter your name here