JDEVELOPER 11G - CRUD EN COMPONENTE FORMULARIO

CRUD es acrónimo de Create Update Delete, es decir, Crear Modificar y Borrar.

Por lo tanto lo que se explica en este post es, como desarrollar el mantenimiento de un formulario de una manera amigable para el usuario.

Este es el enlace al post original:

http://andrejusb.blogspot.com/2008/09/jdeveloper-11g-crud-in-adf-form.html

Este post esta basado en la aplicación ejemplo desarrollada por Andrejus-UndoCreate.zip. Este ejemplo esta basado en el esquema estándar HR, antes de ejecutar la aplicación por favor aseguraros de que tenéis la conexión a base de datos definida correctamente.

1) Funcionalidad Buscar

Por defecto, cuando usamos la funcionalidad ADF Search form, los parámetros introducidos en el formulario de búsqueda, son guardados y se enseñan otra vez cuando el usuario reabre el formulario en modo búsqueda.

Sin embargo, puede que esto no sea lo que quieren los usuarios, que normalmente, prefieren no ver los parámetros de la consulta anterior. Por ejemplo, cuando algún parámetro de búsqueda es introducido:

La búsqueda es ejecutada y el resultado devuelto:

Y ahora, cuando el usuario vuelve a presionar el botón Búsqueda, el criterio de búsqueda anterior será borrado. En ADF no se borra por defecto, pero si lo hará en esta aplicación ejemplo de Andrejus.

Los parámetros de búsqueda anteriores se borran ejecutando una combinación de las acciones Rollback, Find, Delete y Create en el método findButton_action() del backing bean asociado al botón de búsqueda.

2) Funcionalidad Buscar – Sin Resultados

Cuando el usuario introduce unos parámetros de búsqueda que no dan ningún resultado y presiona el botón buscar, por defecto se devolverá un Formulario vació. Ejemplo de un criterio de búsqueda que no existe:

Formulario vació devuelto por defecto:

En la aplicación de ejemplo, se ha cambiado este comportamiento por defecto en el método executeButton_action() del backing bean. En este método, se comprueba si el iterador esta vació y en ese caso volvemos a Find mode y devolvemos un mensaje de informacion - 'No se han encontrado resultados!':

En este caso no se limpia el criterio de búsqueda.

3) Función deshacer en el modo Crear

Cuando el formulario esta en el modo crear, el usuario prefiere tener 3 opciones, guardar los datos introducidos y volver al modo de edición, limpiar los datos introducidos y seguir en el modo crear, y cerrar el modo crear abriendo el modo buscar:

Si fueran solo dos casos, guardar los datos o abrir el formulario en modo búsqueda, todo iría mas o menos bien, pero hay un problema cuando el usuario quiere limpiar los datos introducidos y quedarse en el modo crear. Con la funcionalidad por defecto de Undo, cuando usamos solo la acción Rollback, el usuario será enviado de vuelta al modo Edit. Para poder cambiar esto, En el método undoButton_action() reinvocamos la inicialización del modo Create, este es invocado, después de la acción por defecto Rollback, esto nos permite limpiar los datos y quedarnos en el modo Create después de que el usuario presione el botón deshacer:

4) Funcionalidad deshacer en el modo Editar

Por defecto, cuando el botón deshacer es presionado mientras estamos en el modo editar, una acción Rollback es ejecutada, los cambios serán descartados y al mismo tiempo el formulario será refrescado y nos mostrara la primera línea del iterador. Esto significa, que mandamos al usuario de la fila que esta modificando a la primera fila del formulario.

Para que este funcionamiento sea mas amigable, Andrejus ha implementado una funcionalidad Rollback customizada, en el método undoButton_action() del backing bean.

En este código, se adquiere del iterador relacionado la fila actual que el usuario esta modificando en ese momento. Al final se aplica el Partial refresh al formulario para visualizar los datos correctos. Para conseguir mas informacion sobre la funcionalidad Rollback seguir este enlace, - JDeveloper and the art of the rollback. Esta funcionalidad puede ser aplicada tanto en 11g como en 10g.

Con la funcionalidad implementada si el usuario esta modificando algún dato:

Y decide borrar todos los cambios presionando el botón deshacer, el formulario se quedara en la misma fila:

5) Funcionalidad Borrar

Cuando el usuario ejecuta la funcionalidad borrar, Andrejus recomienda hacer commit de la transacción al mismo tiempo. En la aplicación de ejemplo desarrollada, cuando el botón borrar es presionado, el método deleteButton_action() es invocado, en ese momento se despliega un pop up de confirmación:

Cuando el usuario confirma la acción de borrar, La acción Commit se ejecuta, y la fila es borrada de la base de datos.

6) Funcionalidad Borrar – Ultima fila

Por defecto cuando el usuario borra la ultima fila, veremos un formulario vació:

Esta acción no es nada amigable para el usuario, es mucho mejor navegar al modo búsqueda automáticamente:

Esta lógica esta implementada en el método deleteDialogListener(DialogEvent dialogEvent) del backing bean:

7) Confirmar los cambios pendientes de hacer

Cuando un usuario esta modificando un dato y hay cambios pendientes(antes de hacer commit o rollback), es mejor no permitir navegar desde la fila actual, Por ejemplo cuando el dato es cambiado y hay cambios pendientes:

Los botones relacionados con la lógica del formulario, Buscar, crear, borrar y los botones relacionados con la navegación del formulario, primero, anterior, siguiente y ultimo, son bloqueados. Y aparece un mensaje de informacion, “Guarda o deshaz los cambios pendientes!” Pidiendo al usuario que confirme o deshaga los cambios pendientes:

La informacion sobre los cambios pendiente la sacamos de bindings.Commit.enabled usando EL. Es suficiente con modificar los datos que vemos en el formulario y bindings.Commit.enabledtrue. devolverá