5.2. Interfaces y Abstracciones
Los componentes de la interfaz de usuario de Vaadin se basan en un esqueleto de interfaces y clases abstractas que definen e implementan las características comunes de todos los componentes y la lógica básica de cómo son serializados los estados del componente entre el servidor y el cliente.
Esta sección proporciona detalles sobre las interfaces de los componentes básicos y abstracciones. El diseño y otras abstracciones del contenedor de componentes se describen en el Capítulo 6, Administrar el Diseño. Las interfaces que definen el modelo de datos de Vaadin se describen en el Capítulo 9, Vincular Componentes a Datos.
Figura 5.2. Interfaces de Componentes y Abstracciones
Todos los componentes implementan la interfaz
Además de las interfaces definidas en el framework Vaadin, todos los componentes implementan la interfaz
5.2.1 Interfaz
La interfaz
Administración del Árbol de Componentes
Los componentes son presentados en la interfaz de usuario jerárquicamente. El diseño es administrado por los componentes de diseño, o más en general por los componentes que implementan la interfaz
El método
Un componente no conoce a su padre cuando el componente es creado, por lo que no puede referirse al padre en el constructor con
La adición de un componente a una aplicación provoca que se active el llamado del método
La lógica del acoplamiento es implementado en
5.2.2
Componentes Campo (
Los Campos son los componentes que tienen un valor que el usuario puede cambiar a través de la interfaz de usuario. La Figura 5.3, "Componentes Campo", ilustra las relaciones de herencia y las interfaces importantes y las clases base.
Figura 5.3. Componentes Campo
Los componentes campo se basan en el framework definido en la interfaz
Los campos están fuertemente acoplados con el modelo de datos de Vaadin. El valor del campo es tratado como una
La descripción de las interfaces field y las clases base se divide en las siguientes secciones.
Interfaz
La interfaz
Figura 5.4. Diagrama de Herencia de la Interfaz
Puede establecer el valor del field con
La interfaz
Cuando el valor de un campo cambia, es desencadenado un
Clase Base
Los componentes de la interfaz de usuario de Vaadin se basan en un esqueleto de interfaces y clases abstractas que definen e implementan las características comunes de todos los componentes y la lógica básica de cómo son serializados los estados del componente entre el servidor y el cliente.
Esta sección proporciona detalles sobre las interfaces de los componentes básicos y abstracciones. El diseño y otras abstracciones del contenedor de componentes se describen en el Capítulo 6, Administrar el Diseño. Las interfaces que definen el modelo de datos de Vaadin se describen en el Capítulo 9, Vincular Componentes a Datos.
Figura 5.2. Interfaces de Componentes y Abstracciones
Todos los componentes implementan la interfaz
Paintable, que se utiliza para serializar ("pintando") los componentes para el cliente, y la interfaz inversa VariableOwner, que es necesaria para des serializar el estado del componente o la interacción del usuario desde el cliente.Además de las interfaces definidas en el framework Vaadin, todos los componentes implementan la interfaz
java.io.Serializable para permitir la serialización. La serialización es necesaria en muchas agrupaciones y soluciones de computación en la nube (cloud computing).5.2.1 Interfaz
ComponentLa interfaz
Component se combina con la clase AbstractComponent, que implementa todos los métodos definidos en la interfaz.Administración del Árbol de Componentes
Los componentes son presentados en la interfaz de usuario jerárquicamente. El diseño es administrado por los componentes de diseño, o más en general por los componentes que implementan la interfaz
ComponentContainer. Este contenedor es el padre de los componentes contenidos.El método
getParent() permite recuperar el componente padre de un componente. Si bien existe un setParent(), que rara vez se necesita cuando por lo general agrega componentes con el método addComponent() de la interfaz ComponentContainer, el cual establece automáticamente al padre.Un componente no conoce a su padre cuando el componente es creado, por lo que no puede referirse al padre en el constructor con
getParent(). Además, no es posible traer una referencia al objeto application con getApplication() antes de tener un padre. Por ejemplo, lo siguiente es inválido:
public class EjemploAcoplar extends CustomComponent {
public EjemploAcoplar() {
// ERROR: No podemos tener acceso al objeto de application aún.
ClassResource r = new ClassResource("smiley.jpg",
getApplication());
Embedded image = new Embedded("Image:", r);
setCompositionRoot(image);
}
}
La adición de un componente a una aplicación provoca que se active el llamado del método
attach() para el componente. En consecuencia, la eliminación de un componente de un contenedor activa el llamado al método detach(). Si el padre de un componente agregado ya está conectado a la aplicación, attach() es llamado inmediatamente desde setParent().
public class EjemploAcoplar extends CustomComponent {
public EjemploAcoplar() {
}
@Override
public void attach() {
super.attach(); // Debe llamar.
// Ahora sabemos quién es finalmente nuestro dueño.
ClassResource r = new ClassResource("sonriente.jpg",
getApplication());
Embedded imagen = new Embedded("Imagen:", r);
setCompositionRoot(imagen);
}
}
La lógica del acoplamiento es implementado en
AbstractComponent, tal como se describe en la Sección 5.2.2, "AbstractComponent".5.2.2
AbstractComponentAbstractComponent es la clase base para todos los componentes de interfaz de usuario. Se trata (sólo) de la implementación de la interfaz Component, implementando todos los métodos definidos en la interfaz.AbstractComponent tiene un único método abstracto, getTag(), el cual devuelve el identificador de la serialización de la clase de un componente en particular. Este tiene que ser implementado cuando (y sólo cuando) se creen componentes totalmente nuevos. AbstractComponent administra gran parte de la serialización de los estados de los componentes entre el cliente y el servidor. La creación de nuevos componentes y la serialización se describe en el Capítulo 11, Desarrollar Nuevos Componentes, y la API de serialización del lado del servidor en el Apéndice A, Definicion del Lenguaje de Interfaz de Usuario (UIDL).Componentes Campo (
Field y AbstractField)Los Campos son los componentes que tienen un valor que el usuario puede cambiar a través de la interfaz de usuario. La Figura 5.3, "Componentes Campo", ilustra las relaciones de herencia y las interfaces importantes y las clases base.
Figura 5.3. Componentes Campo
Los componentes campo se basan en el framework definido en la interfaz
Field y de la clase base AbstractField.Los campos están fuertemente acoplados con el modelo de datos de Vaadin. El valor del campo es tratado como una
Property del componente field. Los campos de selección permiten la administración de elementos seleccionables a través de la interfaz Container.La descripción de las interfaces field y las clases base se divide en las siguientes secciones.
Interfaz
FieldLa interfaz
Field hereda la superinterface Component y también la interfaz Property para tener un valor para el campo. AbstractField es la única clase que implementa directamente la interfaz Field. Las relaciones se ilustran en la Figura 5.4, "Diagrama de Herencia de la Interfaz Field".Figura 5.4. Diagrama de Herencia de la Interfaz
FieldPuede establecer el valor del field con
setValue() y leerlo con el método getValue() definido en la interfaz Property. El tipo de valor actual depende del componente.La interfaz
Field define una serie de atributos, que se pueden recuperar o manipular con el setters y getters correspondiente.-
description
Todos los campos tienen una descripción. Tenga en cuenta que si bien, este atributo se define en el componenteField, el cual es implementado enAbstractField, que no implementa directamente aField, pero sólo a través de la claseAbstractField.
required
Cuando está activado, un indicador de (por lo general el carácter * asterisco) es mostrado a la izquierda, arriba, o hacia la derecha del campo, dependiendo del diseño que lo contiene y si el campo tiene un título. Si estos campos son validados pero están vacíos y se activa la propiedadrequiredError(ver más abajo), se muestra un indicador de error y el error del componente se establece en el texto definido con la propiedad error. Sin la validación, el indicador requerido no es más que una guía visual.
requiredError
Define el mensaje de error a mostrar cuando se requiere un valor para un campo, pero no se ingresa nada. El mensaje de error se establece como el error del componente para el campo y por lo general se muestra en un texto de ayuda cuando el puntero del mouse se desplaza sobre el indicador de error. El componenteFormpuede mostrar el mensaje de error en un área indicadora de error especial.
Field hereda a Property.ValueChangeListener para permitir escuchar los cambios de valor en los campos y Property.Editor para permitir editar los valores.Cuando el valor de un campo cambia, es desencadenado un
Property.ValueChangeEvent para el campo. No debería implementar el método valueChange() en una clase que herede a AbstractField, ya que se ha implementado en AbstractField. En su lugar, debe implementar el método explícitamente añadiendo la implementación del objeto como un oyente.Clase Base
AbstractFieldAbstractField es la clase base para todos los componentes field. Además de las características de los componentes heredadas de AbstractComponent, esta implementa varias características definidas en las interfaces Property, Buffered, Validatable, y Component.Focusable.
Anterior Capítulo 5. Componentes de Interfaz de Usuario |
Siguiente 5.3. Características Comunes de los Componentes |
