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 Essentials + GlassFish Server OSE + JDeveloper, un entorno de desarrollo Java EE completo a coste cero
Hace ya unos meses que Oracle puso a disposición de la comunidad de desarrolladores su framework ADF Essentials. Se trata de un conjunto de librerías de componentes que cubre todas las capas de la arquitectura JavaEE. Las aplicaciones que hagan uso de ADF Essentials podrán ejecutarse en cualquier servidor JavaEE (o en cualquier contenedor de servlets, siempre que no usemos elementos propios de Java Enterprise, tales como EJB u otros). En estos momentos Oracle lo soporta sobre Oracle WebLogic Server 11g (WLS), GlassFish 3.1 (GF), and WebSphere 7.
Como muchos de vosotros ya conocéis, Oracle ADF es un producto que lleva mucho tiempo en el mercado y requiere una licencia de pago, bien de forma separada (TopLink and Application Development Framework) o asociada sin coste adicional a la licencia de WebLogic Server. Ahora Oracle ofrece ahora una versión gratuita de ADF (ADF Essentials) que incluye una serie de limitaciones relativas a ciertos componentes pero que puede ser perfectamente válida en muchas ocasiones (ver documento de preguntas frecuentes)
Las librerías o componentes de ADF que no se incluyen en Essentials son las siguientes: Oracle ADF Mobile, Oracle ADF Desktop Integration, Oracle ADF Security, Oracle ADF Web Service Data Control, Oracle ADF Remote Taskflows, Oracle ADF Business Component’s Service Interfaces, Oracle ADF Data Controls for BI, Essbase y BAM, Características de Integration con Oracle Fusion Middleware tales como MDS, OPSS, OWSM, Enterprise Manager y MBeans, High Availability and Clustering.
Pues bien, si miramos detenidamente la totalidad de características de las que no podemos disponer, nos daremos cuenta de que muchas limitaciones se refieren a necesidades de integración con WLS. Si disponemos de WLS podemos utilizar ADF en vez de ADF Essentials (como hemos comentado, tenemos cubierta la licencia de ADF dentro de WLS), así que estas limitaciones no son tales.
Con todo esto, comparándolo con el resto de frameworks a disposición de la comunidad, ADF Essentials se posiciona como una de las mejores soluciones en su categoría. Hay dos aspectos importantes para los que desarrollamos habitualmente en ADF que echaremos en falta si cambiamos WLS por GF (u otro servidor): la seguridad ADF y los DataControls para los Web Services, pero son dos aspectos para los que disponemos de estándares propios de JEE (por ejemplo JAAS).
Si tenemos en cuenta que la licencia de JDeveloper no supone coste alguno, tenemos a nuestra disposición uno de los mejores entornos de desarrollo Java Enterprise. Además, nos permitirá distribuir nuestras aplicaciones sobre cualquier plataforma sin cargar coste de licencias a nuestros clientes.
Leer más…
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.
¿Por qué ADF Mobile y no otro framework?
Ya os expliqué en este post las características básicas de ADF Mobile. Hoy os voy a dar las (mis) razones por las que considero más productivo trabajar con este entorno en vez de utilizar otros frameworks.
La principal razón es que puedo escribir la lógica de la aplicación en Java en vez de usar JavaScript, Phyton u otro lenguaje:
1. Java me ofrece un tipado fuerte, por tanto las aplicaciones son menos propensas a errores
2. Trabajando con Java, depurar las aplicaciones es infinitamente más fácil que con JavaScript
3. El coste de mantenimiento de Java es menor que en el caso de JavaScript (el coste de desarrollo también es menor)
4. Las arquitecturas basadas en Java hoy por hoy ofrecen entornos basados en componentes y una robusta capa de binding que me va a permitir desarrollar con menos codificación al trabajar de forma declarativa. Me facilita la separación entre las capas de negocio y presentación (buenas prácticas de diseño) y dispongo de un enlazado automático y estándar entre ambas capas, con las ventajas que eso supone: mantenibilidad y fiabilidad.
5. Dispongo de un entorno de desarrollo que me ofrece herramientas de transformación de modelo, búsqueda y reemplazo de variables o de cualquier elemento del lenguaje (en javascript si por ejemplo busco y reemplazo en todos los archivos, luego tengo que testear, testear y testear), JavaDoc, etc.
6. Puedo reutilizar modelos de negocio de mis servidores corporativos (a través de web services)
7. Seguridad integrada
No se trata de una discusión de si Java es mejor que Javascript, sino de entender que cada lenguaje tiene unas características que lo hacen más adecuado para construir ciertos elementos pero no tanto para hacer otras cosas.
JavaScript es útil para manejar eventos de la Interfaz de usuario, y así lo utilizo en mis aplicaciones ADF Mobile. No renuncio a nada, pero por suerte tengo Java y lo utilizo para programar la lógica de la aplicación, con la solidez que nos da modelar y construir aplicaciones JEE (también hay otras tecnologías válidas para generar aplicaciones empresariales). De este modo mi lógica de negocio es independiente del cliente web que ejecute el Javascript. Estoy ganando en robustez.
¿Qué supone disponer un framework basado en estándares Java? Supone que podemos usar las facilidades de binding de Java, aprovecharnos del IDE de desarrollo (JDeveloper) y de sus herramientas de diseño.
Este apartado me sigue maravillando. Importo a mi proyecto un módulo de datos con sus JavaBeans correspondientes desde cualquier proyecto corporativo existente, hago click con el botón derecho sobre el JavaBean, selecciono Crear DataControl, arrastro una lista de datos y la suelto sobre la página que estoy diseñando, escojo que quiero que me lo genere como una lista y ya tengo mi lista de datos en la página. He tardado minuto y medio y tengo un diseño correcto basado en la capa de bindings de Java EE sin errores en el código.
Continúo creando mi aplicación: me voy a la lista y le digo que cuando se seleccione un elemento dispare la acción ir_a_elemento (previamente establezco gráficamente mediante el editor de propiedades el parámetro que indica qué elemento de la lista es el seleccionado) y diseño la navegación de la página en el editor de taskflows (gráficamente) para que la capa de control (una capa que no existe en Javascript, y que nos aporta diseño estructurado) sepa como navegar a la página del elemento. Una página que me ha costado otro minuto y medio diseñar partiendo de los objetos de datos que he creado en el apartado anterior.
Como la aplicación requiere más funcionalidad, seguramente tengo que escribir código: por ejemplo, necesitaré recuperar y guardar los clientes en la base de datos. Pues bien, tengo dos posibilidades: guardarlos en el servidor corporativo o en la base de datos local (se guardarían encriptados, viene de serie). Suponiendo el primer caso, necesitaré obtener el WSDL (contrato) del servicio y generar un componente de datos basado en SOAP o Rest. Ya sólo debo ligar las páginas con los atributos de este componente en vez de utilizar los del modelo de datos. Si necesito usar la base de datos local (no excluyente con el acceso remoto a datos), implemento las operaciones de guardar y recuperar en el JavaBean y me bastará arrastrar la operación de guardar sobre la página y decirle que quiero que me genere como un botón de comando.
En un momento dado, se produce un error en mi aplicación. ¿Qué hago? ¿Activo el log y añado trazas en el código? No tengo claro dónde está el error, pero ADF Mobile está integradísimo en JDeveloper y puedo activar la facilidad de debug (otra cosa que se complica cuando estoy desarrollando tan solo en Javascript).
Además, elijo ADF Mobile, porque ofrece todas estas ventajas en un entorno integrado. Si tu framework de desarrollo no incluye algunos elementos (librerías de cifrado, herramientas de binding, depuradores de código, capa de control, …) vas a tener que buscarlos fuera, y luego tendrás que responsabilizarte de la integración. Esto implica que con cada nueva versión de cada librería corres el riesgo de que otras partes dejen de funcionar, por lo que decidirás no actualizar nunca y tu tecnología de trabajo irá quedando obsoleta.
Si tu framework te ofrece todo lo que necesitas, y te permite desarrollar y mantener la facilidad y rapidez que tu deseas, sigue adelante con él. Ahora bien, si no estás del todo satisfecho, prueba el funcionamiento de ADF Mobile.
Desarrollo de aplicaciones móviles híbridas con ADF Mobile
Como publicamos hace 2 meses, Oracle ha sacado al mercado ADF Mobile, su nuevo framework para el desarrollo de aplicaciones para tablets y smartphones, basado en una arquitectura híbrida y un conjunto de módulos y herramientas destinadas a producir aplicaciones seguras.
En próximos posts iremos hablando de distintos aspectos de este framework, pero primero: ¿Qué es una arquitectura híbrida? ¿Qué características tiene? ¿En qué se parecen y en qué se diferencian las aplicaciones desarrolladas con este framework de las aplicaciones nativas o de las aplicaciones web?
Intentemos clarificar los 3 tipos de enfoque a la hora de desarrollar aplicaciones mobile:
Aplicaciones nativas
Se desarrollan utilizando el SDK particular de cada sistema operativo. Se consigue un muy buen rendimiento y se aprovechan al máximo las características del dispositivo (cámara de fotos, gps, etc.) pero, a cambio de estas ventajas, la aplicación no podrá ejecutarse en otro sistema operativo. Por tanto, hacer una aplicación multidispositivo tiene un coste de desarrollo elevado ya que hay que hacer desarrollos distintos para cada sistema operativo, y en tecnologías dispares, con lo que o requerimos de un equipo de desarrolladores más numeroso o con unos conocimientos más amplios.
Aplicaciones web
Típicamente se ejecutan dentro de clientes WEB (principalmente navegadores), en entornos cliente/servidor y utilizan tecnologías de la parte del cliente tales como HTML, CSS y Javascript. Estas aplicaciones residen en servidores web que atienden las solicitudes de los clientes transformando y enviando documentos HTML para que éstos los presenten al usuario.
Las aplicaciones web ofrecen un alto grado de reutilización de código, pero nos obligan a tener conexión en el dispositivo para acceder al servidor web. El coste de desarrollo para estas plataformas es notablemente inferior si lo comparamos con los costes de las aplicaciones nativas e híbridas.
Aplicaciones híbridas
Están construidas de tal manera que son capaces de ejecutar código nativo y también pueden interpretar contenido web, de tal manera que el usuario ve conjuntamente información de los dos tipos. Además, las páginas html (totalmente o en parte) pueden provenir de cualquier servidor web o residir en el propio dispositivo. De esta forma disponemos de lo mejor de cada arquitectura. Por ejemplo, una aplicación híbrida nos puede presentar en pantalla una página HTML5 sobre la que se muestra la posición actual proporcionada por el GPS. El coste de desarrollo es similar al de las aplicaciones web y nos permite preparar las aplicaciones para trabajar sin necesidad de estar conectadas al servidor, es decir offline.
Muy bien, ahora que ya sabemos distinguir las aplicaciones existentes en los dispositivos móviles ¿qué estrategias se han empleado a la hora de diseñar los frameworks destinados a producir aplicaciones híbridas?
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 Mobile Components Demo
Prueba esta demo que simula los componentes disponibles en ADF Mobile.
Sólo funciona desde Safari y Chrome porque requiere un browser que soporte webkit.
ADF tips: Integrando Web Services y Business Componets
A veces nos encontramos con la necesidad de mostrar en la misma fila de una tabla campos procedentes de diferentes fuentes de datos (‘data sources’). Puede darse el caso, por ejemplo, de que necesitemos cruzar mediante una operación ‘JOIN’ dos tablas que se encuentran en distintas Bases de Datos. También es posible que algunos atributos se encuentren en la B.D. y el resto deban obtenerse mediante un Web Service. Este post muestra los pasos a seguir para implementar una solución para este segundo escenario.
Vamos a describir de forma concisa el problema:
- Disponemos de una tabla en la B.D. donde se registran a modo de log todas las conexiones a nuestro sistema. Se guardan dos atributos, la fecha de conexión y la dirección IP de la máquina que se conectó.
- Tenemos que diseñar una pantalla que presente de forma tabular el log de conexiones con las siguientes columnas: fecha, IP y una tercera columna con el nombre del país al que pertenece la dirección IP.
Los dos primeros campos, los tenemos, pero la información correspondiente al tercero, ¿de dónde la obtenemos? Muy sencillo: existen varios Servicios Web que nos proporcionan este dato, uno de los más conocidos es GeoIP. Trabajar con él será fácil: nosotros le damos una dirección IP y el WS nos responde con el nombre del país.
¿Y cómo pegamos lo uno con lo otro, y en que lugar? El punto de encuentro está claro: en la capa del modelo, exactamente en el mismo ViewObject donde se realiza la consulta sobre la tabla de Log; añadimos un nuevo atributo llamado Country y guardamos los cambios. Una vez hecho esto, editamos la clase que implementa el registro del ViewObject y sobrescribimos el método getCountry() para que se comunique con el Web Service, consiga el país y lo devuelva. No lo hará directamente, usaremos un JavaBean para ocultar y envolver las llamadas al servicio.
Hay que hacer notar, que estamos planteando un caso muy sencillo, basta con utilizar un ViewObject de sólo lectura y no basado en entidad. Si los campos de la B.D. tuvieran que ser modificables, entonces diseñaríamos una vista basada en entidad y todo lo dicho para la columna externa (Country) seguiría siendo válido. Otro caso de uso un poco mas complicado contemplaría la posibilidad de trabajar con WS que proporcionan operaciones CRUD (create, read, update, delete). Entonces crearíamos entidades basadas en Web Services (y tendríamos que trabajar a nivel de entidad ocultando el origen de datos a los ViewObjects), pero eso lo dejamos para un futuro post.
Pongámonos manos a la obra:
1. Creamos un proyecto nuevo en nuestra aplicación y a partir del WSDL del servicio construimos un proxyService (de tipo JAX-WS, con el ‘endpoint‘ de la versión 1.2)
2. Creamos un JavaBean, para envolver la llamada al servicio. A partir de este Bean tendremos la posibilidad de crear un DataControl que nos permita trabajar de forma declarativa con los datos las estructuras del WS. El método getGeoIP() se encarga de hacer la llamada a la operación del WS que nos interesa.
3. Diseñamos el ViewObject (LogView1) a partir de la tabla Log y le añadimos un atributo nuevo, Country.
4. Sobrescribimos el método getCountry() en la implementación del registro de LogView1, para que obtenga a través d nuestro JavaBean el país correspondiente a la dirección IP.
5. Diseñamos la página con la tabla de log, arrastrando y soltando el DataControl correspondiente a la vista LogView1 sobre la página, ejecutamos y vemos el resultado final.
Presentación homogénea de columnas que provienen de diferentes fuentes de datos
De esta forma en cinco sencillos pasos hemos conseguido resolver el problema. Seguramente no es muy eficiente llamar al servicio para cada fila, para mejorar esta situación usaremos nuestro JavaBean. Teniendo en cuenta que este tipo de servicios web ofrece operaciones que permiten pasar como parámetro listas de elementos en vez de elementos individuales y de igual manera devuelven listas de resultados, podremos invocar la operación del WS una vez y mantener en un HashMap la lista de paises, evitando así una invocación por cada registro.
Bienvenido Oracle ADF Mobile!
Ya es oficial: ha salido al mercado Oracle ADF Mobile. Con esta extensión del framework ADF, Oracle completa las opciones que ofrece su plataforma de Middleware a la hora de desarrollar aplicaciones, permitiendo crear aplicaciones nativas para dispositivos móviles.
Las características principales que convierten ADF Mobile en un gran producto para soluciones de movilidad empresariales son:
- Desarrollo unificado para distintas plataformas (develop once, deploy anywhere): de momento iOS y Android
- Acceso a funcionalidades del dispositivo: cámara, gps, contactos, correo…
- Capacidad de trabajo offline: utilizando una base de datos local
- Seguridad: aplicaciones integradas en la política de seguridad corporativa (SSO, Oracle Access Manager)
Todo esto con un desarrollo basado en lo que ya conocemos de ADF 11g (task flows, data controls…) y SOA (el proveedor de datos remoto natural para este tipo de aplicaciones), y por tanto, con una mayor facilidad de aprendizaje por nuestra parte.
avanttic ha formado parte del programa de beta testing, siendo el único partner español que se ha incorporado al mismo. Durante los meses que ha durado el programa hemos podido comprobar las capacidades del producto, ayudando a su mejora mediante el aporte de sugerencias y casos de uso derivados de los contactos con distintos clientes. Esto nos ha permitido, a fecha de hoy, tener varios prototipos disponibles y estar desarrollando ya nuestro primer proyecto para un cliente en ADF Mobile, con garantías tecnológicas y confianza en el producto.
Podéis empezar a descubrir qué ofrece el framework en el site del producto en la web de Oracle y descargarlo aquí. También podéis leer la nota de prensa.
Contacta con nosotros si quieres que te enseñemos los prototipos que tenemos preparados o deseas más información.
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:
Nuestra red social |
|
|
