¿Cómo y cuándo debo cargar el modelo desde la base de datos para JSF dataTable?
Tengo una tabla de datos como la siguiente:
<h:dataTable value="#{bean.items}" var="item">
Me gustaría completarlo con una colección de la base de datos obtenida de un método de servicio para que se presente inmediatamente cuando se abre la página durante una solicitud inicial (GET). ¿Cuándo debo llamar al método de servicio? ¿Y por qué?
- Llámelo antes de que se cargue la página. ¿Pero cómo?
- Llámelo durante la carga de la página. ¿Cómo?
- Llámalo en el método getter. Pero se llama varias veces.
- ¿Algo más?
Hazlo con el @PostConstructmétodo del frijol.
@ManagedBean
@RequestScoped
public class Bean {
private List<Item> items;
@EJB
private ItemService itemService;
@PostConstruct
public void init() {
items = itemService.list();
}
public List<Item> getItems() {
return items;
}
}
Y deje que la valuereferencia sea la propiedad (¡no el método!).
<h:dataTable value="#{bean.items}" var="item">
Tiene @PostConstructla ventaja de que se ejecuta después de la construcción y la inyección de dependencia. Entonces, en caso de que esté utilizando un EJB para realizar la tarea de interacción con la base de datos, definitivamente @PostConstructsería el lugar correcto ya que las dependencias inyectadas aún no estarían disponibles dentro de un constructor normal. Además, cuando se utiliza un marco de gestión de beans que utiliza servidores proxy, como CDI @Named, el constructor puede llamarse o no de la forma esperada. Se puede llamar varias veces durante la inspección de la clase, la generación del proxy y/o la creación del proxy.
Al menos no realice el trabajo de interacción con la base de datos en el captador, a menos que sea una carga diferida y realmente no pueda hacer nada más. Es decir, se invocaría durante cada ronda de iteración. Llamar al método de servicio durante cada ronda de iteración es simplemente ineficiente y puede terminar en efectos secundarios "extraños" durante la presentación y las devoluciones de datos, como que los valores antiguos de la base de datos aparentemente todavía permanezcan en el modelo en lugar de los nuevos valores enviados.
Si confía en los parámetros de solicitud GET, utilice <f:viewParam>y <f:viewAction>en su lugar. Consulte también Crear páginas maestras y de detalles para entidades, cómo vincularlas y qué alcance de bean elegir .
Si desea conservar el modelo (la itemspropiedad) en todas las devoluciones de datos en la misma vista (por ejemplo, tabla/diálogo CRUD), cree el bean @ViewScoped; de lo contrario, el modelo no estará sincronizado con la vista cuando el mismo modelo se edite simultáneamente en otro lugar. . Consulte también Creación de una tabla y un cuadro de diálogo maestro-detalle, cómo reutilizar el mismo cuadro de diálogo para crear y editar .
Si utiliza @Versionla función JPA en el modelo, puede tratar OptimisticLockExceptioncon ella y mostrar un mensaje como "Los datos han sido editados por otra persona, actualice/revise si los cambios deseados son los previstos". Consulte también Permitir que la capa de presentación (JSF) maneje las excepciones comerciales de la capa de servicio (EJB) .
Ver también:
- Por qué JSF llama a captadores varias veces
- ¿Para qué se pueden utilizar <f:metadata>, <f:viewParam> y <f:viewAction>?
- ¿Cómo elegir el alcance del frijol adecuado?
- Controlador JSF, Servicio y DAO
