Archivo
ADF tips: Control de cambios pendientes
El control de cambios pendientes cuando el usuario abandona una página es siempre un problema muy a tener en cuenta, sobretodo cuando el usuario utiliza formas de navegación no controladas por la aplicación (como el botón atrás, cerrar el navegador, refrescar la página…).
ADF ofrece una manera muy sencilla de alertar al usuario cuando tiene cambios pendientes, simplemente debemos añadir el atributo uncommittedDataWarning dentro del tag af:document; como se muestra en la imagen.
Esta nueva propiedad provoca que cuando el usuario intenta cerrar el navegador, refrescar la página, ir atrás o una acción similar, salte un popup genérico que le alerte de que si continua puede perder sus cambios.
Además es posible forzar a que este aviso sea lanzado cuando se haga uso de algún elemento de navegación dentro de la propia pantalla, por ejemplo al pulsar un botón o hacer un cambio de pestaña. Para ello debemos añadir el atributo af:checkUncommittedDataBehavior dentro del componente deseado.
Aunque es una solución válida para evitar salidas descontroladas del navegador, en algunos casos puede que necesitemos personalizar este popup de alerta. Por ejemplo para ofrecerle al usuario la opción de guardar sus cambios desde el propio popup, forzar a deshacer todos los cambios antes de permitir la navegación o tal vez darle un aspecto más amigable al aviso. Para ello podemos acceder a la comprobación que internamente el framework ejecuta por nosotros para saber cuándo debe mostrar el mensaje de aviso; teniendo la opción de por ejemplo abrir un popup de aviso propio.
En resumen, gracias a la opción de uncommittedDataWarning podemos alertar al usuario de una forma rápida y eficaz de que va a perder los cambios pendientes, y en caso de que el aviso genérico no cumpla con todos nuestros requisitos, existe una forma alternativa de hacer la misma comprobación y controlar manualmente todas las opciones que el usuario tendrá disponibles.
ADF tips: Versionado de aplicaciones ADF en WebLogic
WebLogic proporciona una utilidad muy interesante: el versionado de aplicaciones, que permite tener al mismo tiempo dos versiones de la misma aplicación desplegada, pudiendo elegir de una forma muy sencilla qué versión es la que dará servicio a las nuevas peticiones.
En entornos de desarrollo puede que esta utilidad no tenga demasiado sentido, pero una vez se llega a entornos en los que hay que garantizar una vuelta atrás rápida y controlada, se vuelve esencial.
Para que WebLogic reconozca automáticamente la versión de la aplicación que se está desplegando hay que crear un fichero MANIFEST.MF dentro de los descriptores del proyecto.
Dentro del fichero MANIFEST.MF hay que incluir el parámetro Weblogic-Application-Version que definirá la versión que se desplegará.
Una vez completado el fichero hay que incluirlo dentro del descriptor de despliegue de nuestra aplicación, desde las propiedades del proyecto.
Además, hay que incluir un filtro para que cuando se genere el EAR no se incluya el fichero manifest creado anteriormente; dado que ya se incluirá al estar definido en el descriptor de despliegue. Si no hacemos este filtro, puede que el despliegue falle. Desde las mismas propiedades de despliegue del EAR se define este filtro.
Así, cuando despleguemos cada nueva versión (modificando el parámetro del fichero manifest), WebLogic mantendrá la versión anterior en un segundo plano, lista para poder volver a la versión anterior si es necesario.
ADF tips: Refinando el “Failed to validate all rows in transaction”
En este tip explicaremos cómo ampliar de forma sencilla y útil la conocida excepción de “Failed to validate all rows in transaction“.
Todo proyecto una vez pasa la fase de desarrollo necesita buenas trazas de log, sobretodo en casos de error. En el momento que una entidad no cumple todas sus validaciones lanza una excepción en el método validateEntity del tipo ValidationException. En las trazas de log por defecto no veremos demasiada información acerca del error, lo que siempre nos complica la resolución del mismo.
Para tener algo más de información podemos crear una entidad genérica de la que hereden el resto de entidades de nuestro proyecto; esto se configura desde las propiedades del proyecto en la opción Business Components:
ADF tips: Validadores personalizados
En este tip explicaremos cómo se puede crear un validador personalizado en la capa de vista utilizando una clase java propia, siendo reutilizable en tantas páginas como queramos.
ADF permite validaciones desde nivel de entity hasta nivel de vista; en este caso nos centraremos en la parte de vista, heredada de JSF. El primer paso es crear la clase Java que implemente la interfaz de javax.faces.validator.Validator; lo que nos obliga a implementar su método abstracto validate:
Una vez creada la clase, debemos registrarla en el fichero faces-config.xml de nuestro proyecto utilizando el wizard:
Ahora sólo queda hacer uso de este validador en una de nuestras páginas. Para ello hay que añadir el tag de <af:validator> dentro de uno de nuestros inputText:
ADF tips: Forzar orden de commit en maestro-detalle
En este tip explicaré cómo evitar problemas a la hora de hacer commit de una transacción en la que se han creado registros dependientes por “foreign key” en base de datos.
Algunas veces por motivos de negocio nos vemos forzados a crear primero los registros dependientes y después el registro padre. Para evitar que a la hora de enviar los datos a base de datos tengamos problemas de que el registro hijo no encuentra su “parent key” tenemos dos opciones.
La primera opción, la más elegante: hacer uso de las asociaciones en modo “composition” entre las entities que forman el maestro-detalle.
Aún así, algunas veces nos vemos obligados a forzar programáticamente el envío de los registros “padre” para evitar problemas. En este caso la mejor opción es sobreescribir el método post-changes de la o las entities “hijas” y forzar el envío del padre antes que el suyo propio.
De esta forma obligamos a enviar a base de datos en el orden correcto de dependencias, con lo que nunca tendremos problemas del tipo “parent key no found”.
ADF tips: Redirección dinámica de task-flows
En este tip explicaremos cómo definir el destino de una acción en un task-flow en tiempo de ejecución.
En la capa controller, ADF permite definir una serie de acciones estáticas en tiempo de diseño. En algunos casos esto puede limitar el diseño y obliga al programador a hacer uso de elementos como routers o regiones dinámicas.
Si decidimos utilizar un router para definir todas las posibilidades de navegación puede elevar la complejidad del task-flow, lo que hace difícil su lectura; además de la pérdida de rendimiento que puede ocasionar.
Si por el contrario mantenemos un task-flow sencillo con una única navegación y hacemos uso de regiones dinámicas solventamos el problema de complejidad en el task-flow, pero cargaremos demasiado la aplicación. Además de hacer menos mantenible esta parte del código.
Sin embargo, desde hace varias versiones de ADF (11.1.1.2) podemos definir la navegación en tiempo de ejecución. Esto quiere decir que sólo debemos indicarle al task-flow que la navegación será de tipo dinámica y introducir una expresión EL con la que obtendrá el objeto TaskFlowId que será interpretado para obtener el task-flow destino.
La expresión EL debe retornar un objeto TaskFlowId creado previamente, por ejemplo:
ADF tips: Transacciones pequeñas y controladas
En una aplicación ADF hay que analizar muy detenidamente la estructura del modelo de nuestra aplicación. Una estructura mal organizada puede llevar a ocasionar problemas muy graves de rendimiento.
Antes de empezar a diseñar una aplicación ADF debemos pensar las transacciones básicas que se van a llevar a cabo dentro de ella, organizando en función de la misma diferentes Application Modules (AM) / View Objects (VO). La práctica de diseñar funcionalidades muy grandes sin tener en cuenta lo que ello conlleva a nivel de rendimiento y tiempo de respuesta suele ocasionar graves problemas, aunque probablemente no los detectaremos hasta realizar pruebas de estrés o directamente en el entorno productivo. Por ello es más que necesario el que los diseños funcionales, técnicos y de modelo de datos estén alineados y sean coherentes entre sí. Esto nos ayudará a controlar el número de elementos en memoria, lo que se traduce en buenos tiempos de respuesta.
Por otra parte, es recomendable controlar mucho el peso de los AM. Debemos tener muy en cuenta que un AM con exceso de VOs será muy pesado a la hora de pasivar; esto ocasiona problemas de rendimiento (tanto en tiempos de respuesta como en consumo de memoria). Y aunque sea muy apetecible el reaprovechar componentes hay que hacerlo con cabeza.
Una práctica muy extendida es el anidar AM como “nested” sin estudiar demasiado las consecuencias. Si tenemos una aplicación modular lo recomendable es que para interconectar módulos se utilicen AM de lógica de negocio. Estos AM deben tener la mínima cantidad de elementos posible para funcionar de forma atómica y en la medida de lo posible no deben tener otros AM anidados. Siguiendo esta práctica conseguiremos controlar las transacciones y el consumo de memoria no se disparará cuando nuestra aplicación sea utilizada por varios usuarios concurrentes.
Por otro lado, no debemos olvidarnos de adaptar el apartado de Tuning de todos y cada uno de los componentes de nuestra aplicación. Con el ajuste apropiado una misma aplicación puede reducir los tiempos y consumos de memoria en gran parte. Una aplicación grande sin tuneo puede ocasionar cuelgues y tiempos de espera prolongados y puede solucionarse con un análisis y configuración de estas opciones.
Nuestra red social |
|
|
