© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Curso avanzado de Fundeweb.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Índice de contenidos Ciclo de vida JSF Immediate="true" Procesamiento parcial Regiones ajax Propiedad process CMIS y Apache Chemistry Birt - Informes Intalio y Fundeweb Genética Patrones de diseño J2EE Fundeweb 2.0

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Ciclo de vida JSF: 1.Reconstrucción del árbol de procesamiento con los datos introducidos por el usuario. 2.Aplicación de los valores reconstruidos en el servidor. 3.Procesamiento de eventos. 4.Validación de valores introducidos. 5.Actualización del modelo. 6.Invocar aplicación (calcular respuesta, redirección, etc…). 7.Renderizado de la respuesta al cliente.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Reconstrucción del árbol de procesamiento con los datos introducidos por el usuario. Aplicación de los valores reconstruidos en el servidor. JSF (Java Server Faces) Procesamiento de eventos Validación de valores introducidos. Actualización del modelo.Invocar aplicación Renderizado de la respuesta

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Reconstrucción del árbol de procesamiento Tras un submit se restaura el árbol de contenido. El controlador examina el contenido y crea los componentes que se requieran por el contenido recibido. El controlador examina el contenido recibido para saber si es una nueva vista o está en una ya creada de antemano. El controlador almacena los ID de las vistas que ha recibido para saber qué objetos debe inicializar y cuales recargar.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Aplicación de los valores reconstruidos en el servidor Cada componente creado en el paso anterior obtiene su valor de la petición recibida en el paso anterior. Los valores recibidos se convierten a los esperados por sus respectivos componentes. Si algún valor no puede convertirse se envía un error de conversión en esta fase. Si un componente es marcado como inmediato, se asigna el valor y se pasa a la etapa de validación antes de tratar el resto de componentes. Si hay algún evento enconlado hasta el momento, JSF lo reenvía en esta fase.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Procesamiento de eventos. En este punto han podido lanzarse errores de conversión de tipos o de validación en caso de valores inmediatos. Estos eventos se capturan y se le indican al controlador. El controlador redirigirá el flujo hacia un estado seguro devolviendo un evento de error en caso de proceder.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Validación de valores introducidos. Se procede a comprobar si los valores introducidos cumplen las restricciones definidas en la aplicación. Estos eventos se capturan y se le indican al controlador. El controlador redirigirá el flujo hacia un estado seguro devolviendo un evento de error en caso de proceder. Se ejecutarán los validadores estándar y los definidos por el usuario en el código fuente. En caso de no cumplirse alguna restricción se lanzará un evento de error y se redirigirá el flujo.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Actualización del modelo. Una vez validados los datos se procede a actualizar el modelo. Se copian los datos en las clases Java que los contienen pasando la información a la parte de control de la aplicación. En este punto los valores copiados son válidos desde el punto de vista de la corrección, aunque pueden ser inválidos para la lógica de negocio.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Invocar aplicación. Con los valores introducidos procedemos a invocar a la lógica de negocio de la aplicación. Tras procesar los datos pasaremos a generar una respuesta o bien a un estado de error. En este punto se persistirán los datos, calculará la redirección, se harán las llamadas a servicios externos, etc…

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Renderizado de la respuesta al cliente. Se genera la página de respuesta al cliente en base al resultado obtenido en la fase anterior. Se tratará el árbol de respuesta para mostrar los elementos que así sean necesarios como sus valores. En caso de haberse producido un error deberá notificarse al cliente en esta redirección.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Immediate = true Confundido con la funcionalidad que permite ajax usando "ajaxSingle = true". Adelanta la fase de validación sólo a los campos con immediate=true. En caso de funcionar correctamente valida el resto de componentes y los envía. Como vemos, en cualquier caso, si todo funciona correctamente se envían todos los valores.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. JSF (Java Server Faces) Immediate = true ¿Qué diferencia hay con ajaxSingle? Immediate true manda siempre todos los valores. ajaxSingle sólo manda el/los valores indicados para que se envíen por lo que el resto de valores no actualizarán el modelo. En general en Fundeweb se aconseja usar ajaxSingle frente a immediate ya que el uso en la mayoría de casos es para evitar la validaciones de determinados campos, que con immediate no se evita.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Regiones ajax Las regiones ajax nos permiten englobar una parte del código para que se envíe en el submit. Nos aporta flexibilidad a la hora de valorar qué componentes queremos que se actualicen en el modelo. Es importante que los elementos que hacen submit dentro de una región ajax sean de tipo ajax. Un error común es incorporar un h:commandButton dentro de una región ajax. El resultado no será el espardo pues h:commanButton hará submit de todo el formulario ignorando la región.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Regiones ajax Ejemplo de código: Si pulsaramos el botón ajax sólo se enviarían "input2" e "input3" Pulsando el botón JSF se envían todos los input.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Propiedad Process Esta propiedad se utiliza en componentes con la propiedad ajaxSingle. Modifica el comportamiento para, en el submit ajax, no solo envía el dato marcado con ajaxSingle, sino todos los componentes que se encuentren en dicha etiqueta. En este caso se enviaría en el evento oblur los input "texto1" e "email".

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. CMIS (Content Management Interoperability Services) Actualmente existen diferentes sistemas para la gestión documental Alfresco dotCMS eXo Platform EMC Documentum El principal problema: API's de acceso no unificadas. CMIS: Estándar de comunicación con gestores documentales.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. CMIS (Content Management Interoperability Services) CMIS unifica la gestión de los contenidos en un punto de acceso común a diferentes gestores documentales. Establece dos canales de comunicación: SOAP REST (Atom Pub) Permite al programador abstraerse de la implementación concreta bajo los servicios que se exponen. Admite extensiones para peculiaridades de los gestores documentales. Ej: Aspectos en Alfresco.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Apache Chemistry Provee una implementación del estándar CMIS Facilita aún más al programador la interacción con el gestor documental. Abstrae de los detalles del protocolo de comunicación concreto utilizado (Soap, REST) Amplia la abstracción de las extensiones que soportan el protocolo de comunicación y las integra con la API propia.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt Generador de informes basado en eclipse. Compuesto por dos componentes principales: Editor de Informes. Generador de Informes (BirtUM) Pretende abarcar el mayor rango de componentes disponibles a la hora de realizar un informe. Centrado en permitir diseñar fácilmente informes de manera gráfica. Objetivo: Descargar a los desarrolladores del trabajo de plasmar en un informe las especificaciones detalladas del cliente.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Herramienta integrada dentro del IDE Eclipse Estructura enfocada al diseño de informes de manera visual. Provee diferentes maneras de acceder a los datos: Directamente sobre BBDD. A través de csv o XML. Vía WebServices. … Define una manera clara de filtrar los datos que queremos tratar en un momento determinado.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes DataSources Un DataSource es la propia fuente de datos. Definimos su tipo y su manera de conectar. Nos permite acceder a la información que necesita el informe. DataSet Es un subconjunto de los datos que provee el DataSource. Sobre ellos podemos realizar operaciones en el informe. Podemos definir tantos DataSet's como subconjuntos queramos.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes DataSet Permite crear datos adicionales. Permite calcular valores en base a los datos incluidos en el.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Parámetros: Birt permite que se definan parámetros de entrada en el informe. Estos parámetros pueden tener varias funciones: Configurar aspectos generales del informe. Proveer el propio origen de los datos en los que se basará el DataSource (por ejemplo en informes a partir de XML). Los parámetros son recogidos por el motor de informes y se procesan antes de la generación del mismo.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Árbol de orígenes de datos: Contiene todos los componentes que aportan datos para generar el informe: DataSource: Origen real de los datos. DataSet: Agrupación de datos. DataCubes: Agrupación cruzada de datos. Parámetros del informe: Parámetros de entrada del informe. Variables: Variables que se usarán durante la generación del informe. A partir de los componentes dados de alta en esta vista, se podrán rellenar las estructuras de datos del informe.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Editor de informes Vista encargada de permitirnos diseñar el informe. Permite el diseño visual o directamente sobre código. Pose una vista "Master Page" para definir la estructura general de todas las páginas. Permite introducir scripts a ejecutar según determinados eventos. Permite editar visualmente el informe. Permite visualizar una vista previa del resultado, siempre que sea posible.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Árbol de elementos Añade a la información del árbol de orígenes de datos la estructura del informe. Muestra de una manera clara y ordenada cómo se "pintan" los componentes del informe. Establece las dependencias entre elementos. Nos permite visualizar los scripts o librerías añadidas al informe.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Birt: Editor de informes Propiedades de los elementos Esta vista permite ajustar parámetros de cada uno de los elementos del informe. Nos permite asignar componentes gráficos a orígenes de datos. Permite realizar filtrados Permite establecer condiciones sobre los componentes. Ej: Decidir si se pinta o no dependiendo de un valor. Permite modificar el aspecto de los componentes. Cada componente, además de la configuración general, añade su configuración propia.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. BirtUM Componente de ATICA para la generación de informes Birt. Expone dos interfaces: Informes BBDD Informes XML Ambas soportan paso de parámetros al servidor. Los informes BBDD devuelven el informe de dos maneras: URL Array bytes. Los informes XML sólo devuelven el informe como Array de bytes.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. BirtUM La generación de informes XML puede devolver dos posibles resultados: PDF XLS (multi hoja) Permite depurar fácilmente con SoapUI la generación de informes desde un cliente. Importante configurar timeouts adecuados para los test.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicio Birt Haciendo uso del editor de informet Birt realizar el diseño de un informe acorde la plantilla proporcionada. Usar el fichero xml proporcionado como entrada de datos. Diseñar con Birt el informe. Previsualizar el informe en PDF.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicio Birt Pasos a seguir: Crear un proyecto Birt y un fichero de informes vacío. Definir la fuente de datos (fichero XML). Modificar el "master page" para definir encabezado y pie de página. Crear DataSet que agrupe todos los libros con su conteido. Crear una tabla que muestre ese DataSet. Crear un DataSet que contenga el precio de los libros y dos columnas calculadas: Libros con precio superiro a 10€ Libros con precio inferior a 10€ Ojo: Hacer uso de propiedades calculadas y filtrado.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Ejercicio Birt Pasos a seguir: Crear Grid para contener el texto necesario. Insertar gráfico de barras y definir condiciones para que cuente los libros que hay por autor. Probar que el informe se imprime correctamente.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Intalio y Fundeweb Intalio es un framework de desarro de procesos de negocio. Permite programar de manera ágil flujos de proceso. Nos habilita para modelar el comportamiento de un negocio concreto. Flujo documental: creación, validación, firma, archiado. Flujos industriales: recogida material, fabricación, envasado, empaquetado, distribución. Flujos administrativos: creación solicitud, revisión de responsable, validación por supervisión, aprobación. Etc …

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Intalio y Fundeweb Basado en la notación BPMN para modelar procesos de negocio. Provee un entorno para desarrollar, compilar y ejecutar nuestros propios procesos.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Intalio y Fundeweb ¿Qué nos permite Intalio? Definir y gestionar: Roles de ejecución. Variables. Interacción entre tareas. Errores o situaciones no permitidas Notificaciones. Conectarse con entidades externas: Bases de datos. Servicios Web.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Intalio y Fundeweb Intalio provee una api para la interactuar con él desde una aplicación externa. Permite ligar aplicaciones existentes con el flujo de un determinado proceso. Soporta intercambio de datos vía XML. Permite aplicar los mecanismos de autenticación y autorización. Permite la personalización detallada del Front-End de la aplicación.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Intalio y Fundeweb ¿Cómo interactúa con Fundeweb? La API de Intalio permite: Enviar y recibir información externa través de XML. Gestionar los procesos. Autentica al usuario que se pretende contectar. Componente de seguridad: Permite la gestión de roles y permisos (autorización). Carga en Intalio el perfil del usuario que intenta ejecutar una determinada acción.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética Es un generador automatizado de PAO's para Fundeweb. Genera las clases y estructuras Java necesarias para realizar llamadas a procedimientos. Actúa sobre la base de datos ORACLE. Basa su funcionamiento en el archivo de especificación de ORACLE. (spec.sql). Analiza dicho fichero y devuelve como resultado la estructura Java que se ajusta a lo indicado.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética: Configuración Configuración de spec.sql Mediante este fichero indicamos los procedimientos a los que vamos a llamar. Genética lo usa de base para generar la infraestructura Java equivalente.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética: Configuración Configuración del Datasource Debemos indicarle a genética dónde se encuentra la base de datos sobre la cual queremos actuar. Para ello lo indicamos en el fichero: spec-parser.properties Una vez indicado, Genética incluirá dicha especificación en los EJB generados en cargados de la ejecución de lo indicado en el fichero spec.sql.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética: Generación Generación de clases Una vez configurado nuestro proyecto podemos proceder a ejecutar la tarea Ant que nos generará las clases: genetica.generate.pao

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética: Generación Una vez generados los ficheros sólo tenemos que copiarlos en nuestro proyecto. Por defecto nos generará los PAO's en la carpeta pao_generation/build/ejb/src/main/java

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Genética: Configuración Configuraciones extras src: directorio donde se generarán las clases PAOs srcTest: directorio donde se generarán las clases de test packageInterface: nombre del paquete de la clase interfaz packageImpl: nombre del paquete de las clase de implementación dataSource: origen de datos donde se encuentra el procedimiento

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Patrones de diseño J2EE ¿Por qué utilizar patrones de diseño? Hacen que las aplicaciones sean fácilmente extensibles. Mejoran la escalabilidad de la aplicación (rendimento). Mejoran la fiabilidad y la depuración de las aplicaciones. Hacen las aplicaciones más claras y uniformes. Existen un gran número de patrones dependiendo de qué capa de la aplicación queremos tratar. Deben tenerse en cuenta en la fase de análisis de la aplicación para mejorar el diseño final.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Patrones de diseño J2EE Patrones en Fundeweb MVC: Modelo Vista Controlador Singleton Factoría Abstracta Adapter Observer

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón MVC (Modelo Vista Controlador) Separa la lógica de la aplicación en tres bloques Modelo: Representa la capa de persistencia que mapea tablas BBDD en objetos JAVA. Vista: Representa el Fron-End de la aplicación. Control: Representa la lógica de negocio de la aplicación. A tener en cuenta: La parte del modelo debe tener objetos sin lógica de negocio y sin inyecciones de otros beans. La parte de la vista no debe contener lógica de negocio.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Singleton Este patron asegura que sólo habrá una única instancia del objeto requerido. Evita tener instancias duplicadas en memoria. Optimiza el uso de los recursos del sistema.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Factoría Abstracta Contexto: Tenemos objetos de la misma familia pero con diferencias estructurales. Este patrón nos permite crear una estructura general para crear cualquier objeto de la misma familia. Estructura: Clase cliente: Quien invoca a la factoría. Factoría abstracta: Interfaz que define los métodos de las factorías concretas. Factoría concreta: Familia de objetos. Instancia concreta que se encarga de crear el objeto deseado. Objeto abstracto: Interfaz que define los objetos de una familia. Objeto concreto: Implementación de un objeto abstracto.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Factoría Abstracta Este patrón es utilizado por Fundeweb para soportar el mecanismo de autenticación múltiple.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Adapter Consiste en transformar la interfaz de un componente en otra que soporte una determinada clase cliente. En ocasiones no podemos modificar los métodos que requiere una clase cliente. Es necesario "adaptar" dicha funcionalidad para que cliente y proveedor de servicio se entiendan.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Adapter Visto con un ejemplo: Supongamos que tenemos un cliente que requiere los métodos: Suma(op1,op2) Resta(op1,op2) La clase que sirve estas operaciones, en cambio sólo tiene este método: RealizaOperacion(op1,op2,operación) Como podemos ver en este ejemplo cliente y servidor no podrían comunicarse pese a que el servidor puede realizar las operaciones que requiere el cliente.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Adapter La solución que propone el patrón Adapter es crear una clase intermedia que exponga la interfaz que requiere el cliente. Esta clase en su implementación llamará al servidor como él espera. Así pues:

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. El patrón Observer Necesario cuando los cambios de estado de un elemento deben ser contemplado por un conjunto de los mismos. Muy extendidos debido a las múltiples interdependencias de estados entre componentes. Un objecto se registra como "listener" de un objeto concreto. Cuando el objeto padre modifica su estado, envía una notificación a todos sus "listener" para que estos actúen como deban.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 Nuevo Framework de desarrollo para aplicaciones J2EE en ATICA. Actualiza las librerías de versiones anteriores e introduce nuevas. Los cambios más destacados: Servidor Weblogic 12.1.2 EJB 3.1 Java 1.7 Seam 2.3 JSF 2.1 Primefaces 4.0 Jboss Forge 1.4

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 ¿Qué se gana? Mejora importante de rendimiento. Mayor cantidad de componentes gráficos. Validaciones en cliente. Simplificación del mecanismo de paginación en tablas. Uso de HibernateSearch que mejora el rendimiento de las búsquedas mediante un sistema de caché. Despliegues simplificados. Permite programar scripts para actualizar/modificar proyectos.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 El módulo EJB está integrado dentro del módulo web. El módulo ear es el que utilizaremos para desplegar en el servidor local. El módulo general contiene el pom principal de la aplicación y la configuración global del proyecto. En los desarrollos Fundeweb 2.0 trabajaremos fundamentalmente con el módulo web y el de los test. Importante: El módulo general visualiza todos los ficheros, pero las modificaciones hechas en él no se plasman en la aplicación.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 Posee nueva estructuración de proyectos. Hay un proyecto por cada módulo: ear, test, web y uno global a todo el proyecto.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fudeweb 2.0 El despliegue de aplicaciones en local se ha simplificado con el nuevo servidor. Ya no son necesarias tareas ant.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 El mayor cambio a nivel de aplicación es la interfaz web. Primefaces 4.0 provee de un gran número de componentes optimizados para JSF 2.x Mejora el comportamiento ajax de sus componentes. Incorpora validadores javascript para agilizar las respuestas de validación. Permite crear nuestros propios estilos visuales de manera rápida gracias a jQueryUI ThemeRoller. http://jqueryui.com/themeroller/

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 JSF 1.2 fue lanzado en 2006. JSF 2.1 fue lanzado en 2010. ¿Qué cambios se han realizado en ese tiempo? Estabilizar bugs encontrados en versiones anteriores. Optimizar el rendimiento general de las aplicaciones. Ampliar la funcionalidad proporcionada y completar la existente. Mejorar la facilidad de uso, por parte de los programadores de la tecnología.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Componentes personalizados Proporciona una manera rápida y cómoda de crear componentes personalizados sin necesidad de usar clases Java, gracias al nuevo elemento "Composite component". Permite incluir listeners, validadores, conversores, etc… a nuestros componentes. Cubre la mayoría de composiciones posibles. La finalidad es ir ampliando la flexibilidad de esta nueva manera de definir componentes.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Ajax Integra Ajax en el framework, frente a versiones anteriores a los que había que añadir las librerías manualmente. Optimiza el ciclo de vida Ajax de versiones anteriores. Permite hacer llamandas Ajax mediante JavaScript.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Gestión del estado JSF 1.X almacenaba el estado del árbol de componentes para mejorar la eficiencia en el repintado de los mismos. Este almacenaje causa problemas de uso de memoria en pantallas con gran número de componentes. JSF 2.X incorpora un mecanismo de almacenamiento parcial del estado. Almacenar el estado inicial es redundante pues siempre podemos calcularlo de manera eficiente. Normalmente no se modifican muchos componentes entre cambios de estado consecutivos. Sólo guardamos los cambios de estado y reconstruimos el árbol a partir de ahí.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Navegación En JSF 1.X la navegación debía definirse explícitamente en los ficheros dispuestos para ello. JSF 2.X mejora este mecanismo añadiendo la navegación implícita. Si JSF 2.X permite no especificar en los ficheros *.page.xml la navegación. El valor devuelto por un método, si coincide con el identificador de una página, hará que JSF redirija el control hacia esa vista.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Nuevos ámbitos ViewScope: Equivalente al scope "Page" que nos proporciona Seam. FlashScope: Similar al scope Event que nos proporciona Seam. CustomScope: JSF 2.X permite definir un scope personalizado en el cual diremos qué beans debe contener. Las instancias permanecen vivas siempre que se referencie a ese scope. Similar al scope Session, pero sólo guardando lo que le indiquemos.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: JSF 2.1 Otras mejoras Mejorada la eficiencia de renderizado de árboles. Nuevas anotaciones para realizar validaciones de nuestros beans. Validación de campos vacíos (JSF 1.X no aplica valicación automática de campos vacíos). Mejora del mecanismo de gestión de excepciones. Nos permite subscribir un manejador a una excepción para tratarla de una manera específica.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: Primefaces Librerías de componentes gráficos para JSF 2.X Mejora y optimiza el "pintado" de los componentes y las animaciones, si las hubiera. Posibilidad de añadir diversos efectos a determinados componentes. Basado en jQuery aumenta notablemente la eficiencia y permite componentes que se pinten dinámicamente. Cubre todos los elementos ofrecidos por RichFaces 4 e incorpora un gran conjunto adicional.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: Primefaces Principales objetivo de Primefaces La eficiencia La estética. Optimización de las llamadas Ajax para minimizar la sobrecarga. Ofrece librerías para programación móvil y php. Configuración de la apariencia rápida y sencilla gracias a ThemeRoller.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0: Primefaces ¿Por qué dejar RichFaces? Bajo número de componentes. Estancados con el paso del tiempo. Baja resolución de incidencias. Componentes estéticamente anticuados. Sus competidores igualan o superan su funcionalidad. Estadísticamente el proyecto está llegando a un punto de estancamiento.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Fundeweb 2.0 Resumen Nueva versión del Framework de desarrollo. Persigue la eficiencia en ejecución y uso de memoria. Incorporación de servirord WebLogic 12.1.2. Actualización de Seam para corregir bugs. Gran cambio en los componentes visuales. Mayor flexibilidad a la hora de diseñar pantallas. Despliegues rápidos sin tareas Ant.

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Curso avanzado de Fundeweb.

Presentaciones similares

Presentación del tema: "© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Curso avanzado de Fundeweb."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Curso avanzado de Fundeweb.

Presentaciones similares

Presentación del tema: "© 2012. Área de las Tecnologías de la Información y las Comunicaciones Aplicadas. Curso avanzado de Fundeweb."— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback