Manual Daw II

Desarrollo de Aplicaciones Web II
CARRERAS PROFESIONALES
CIBERTEC
DESARROLLO DE APLICACIONES WEB II
NDICE
Presentacin Red de contenidos Unidad de aprendizaje 1 Tema 1 : Struts 2 : Gestin de componentes RIA 1.1. : Etiquetas Ajax en Struts 2 1.2. : Libreras de Dojo y Struts 2 1.3. : Libreras JQuery Struts 2 Tema 2 : Struts 2: Tpicos de Seguridad y validacin 2.1. : Etiqueta Token 2.2. : Validaciones
Pgina
7 8
10 11 11 23 30 30 32
Unidad de aprendizaje 2 Tema 1 : Introduccin a la API de Persistencia 1.1. : Entidad 1.2. : Metadata 1.3. : EntityManager 1.4. : Unidad de Persistencia 1.5. : Operaciones bsicas 1.6. : Transacciones 1.7. : Ciclo de vida de una Entidad Tema 2 : OR-Mapping con JPA 2.1. : Anotaciones 2.2. : Manejo de la Llave Primaria 2.3. : Generacin de la Llave Primaria 2.4. : Llave primaria compuesta 2.5. : Objetos embebidos Tema 3 : Relaciones entre entidades 3.1. : Conceptos bsicos 48 48 49 50 51 43 55 55 60 60 65 65 69 71 76 76
CIBERTEC
3.2. : Relacion Many To One 3.3. : Relacion One to One 3.4. : Bidireccionalidad de la relacin One-To-One 3.5. : Relacin One To Many 3.6. : Relacin Many To Many 3.7. : Opciones de Fetch Tema 4 : Lenguaje de Consultas JPQL 4.1. : Introduccin a JP-QL 4.2. : Consultas dinmicas 4.3. : Consultas nombradas 4.4. : Uso de parmetros 4.5. : Ejecucion de Queries 4.6. : Sintaxis de JPQL
78 80 81 82 84 87 90 90 95 97 99 100 102
Unidad de aprendizaje 3 Tema 1 : Arquitectura de JSF, Configuracin y estructura bsica 1.1. : Introduccin a JSF 1.2. : Arquitectura de JSF 1.3. : Ciclo de vida de un request 1.4. : Facelets 1.5. : Managed Bean 1.6. : Lenguaje de Expresiones JSF 1.7. : Backing Beans Tema 2 : Componentes de Interfaz de usuario 2.1. : Introduccin 2.2. : Arquitectura de Componentes UI 2.3. : Librera Core. 2.4. : Librera HTML. 2.5. : Librera User Interface 2.6. : Librera de Componentes Compuestos. Tema 3 : Conversiones, Validaciones y Eventos 3.1. : Introduccin 3.2. : El sistema de Conversin de JSF 108 108 109 113 117 125 128 131 134 134 135 139 145 154 154 158 158 158
CIBERTEC
3.3. : El sistema de Validacin de JSF 3.4. : El sistema de Mensajes de JSF 3.5. : El modelo de Eventos de JSF Tema 4 : Tpicos avanzados de JSF I 4.1. : JSF y AJAX 4.2. : Integracin JSF + JPA 4.3. : Empleando otras implementaciones de JSF Tema 5 : Tpicos avanzados de JSF II 5.1. : Tablas JSF : Facets, dataTable y panelGrid. 5.2. : Mantenimiento de tablas
161 162 166 174 174 177 178 184 184 191
Bibliografa Anexo 1 Anexo 2
197 199 211
CIBERTEC
CIBERTEC
PRESENTACIN
El curso de Desarrollo de Aplicaciones Web II pertenece a la lnea de Programacin dentro de la Carrera de Computacin e Informtica y brinda un conjunto de conocimientos y herramientas que permitirn a los alumnos poder desarrollar aplicaciones web de n-capas utilizando los frameworks Java : Struts2, Java Persistence API ( JPA ) y Java Server Faces ( JSF ). El Manual del curso ha sido diseado bajo la modalidad de Unidades de Aprendizaje, las que desarrollan determinados temas a lo largo de las semanas establecidas para el dictado del curso. Cada captulo del manual indica los temas a ser tratados, los logros que se deben alcanzar y los contenidos que se deben desarrollar. Finalmente, se encontrar las actividades recomendadas que el alumno deber desarrollar para reforzar lo trabajado y aprendido en la clase. Se incluye bibliografa y recursos de Internet que puede colaborar en el logro de un autoaprendizaje efectivo. El curso es eminentemente prctico, pero requiere horas adicionales de investigacin y prctica por parte del alumno. Se inicia con un repaso del Framework Struts-2 para abordar las caractersticas que brinda al incorporar funcionalidades de tipo AJAX con los plug-ins de Dojo y jQuery as como la utilizacin de las opciones de validacin. Posteriormente, se desarrolla ampliamente los conceptos de OR-Mapping con la especificacin JPA (Java Persistence API) y su implementacin en EclipseLink: se abordan las anotaciones, mapeo y relaciones entre entidades as como los fundamentos bsicos de JP-QL para la construccin de consultas. Finalmente, la tercera unidad del manual aborda la especificacin JSF (Java Server Faces ) tratando de abarcar gran parte de la funcionalidad que proporciona.
CIBERTEC
RED DE CONTENIDOS
Desarrollo de Aplicaciones Web II
Tpicos avanzados de Struts 2
Java Persistence API ( JPA )
Java Server Faces ( JSF )
Gestin de componentes RIA
Seguridad y Validacin
Tpicos avanzados de JSF
Conversiones, Validaciones y Eventos Introduccin a la API de Persistencia
OR-Mapping con JPA
Componentes de Interfaz de usuario
Relaciones entre entidades
Arquitectura de JSF, Configuracin y estructura bsica
Lenguaje de Consultas JPQL
CIBERTEC
UNIDAD DE APRENDIZAJE
MANEJO DE TPICOS AVANZADOS CON STRUTS 2

LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno, empleando opciones de AJAX y facilidades avanzadas que proporciona el framework Struts-2, construye una aplicacin web de n-capas y la despliega dentro de un servidor de Aplicaciones Java EE compatible.
TEMARIO
Tema 1: Struts 2 y gestin de Componentes RIA 1.1 Etiquetas AJAX Struts 2 1.2 Libreras DOJO Struts 2. 1.3 Librera jQUERY Struts 2. Tema 2: Tpicos de Seguridad y Validacin con Struts 2 2.1 Etiqueta <s:token> 2.2 Validaciones en Struts 2.
ACTIVIDADES PROPUESTAS
Los alumnos implementan una sencilla aplicacin web para recordar los conceptos de Struts 2. Los alumnos implementan opciones de una aplicacin web con Struts 2 y para utilizar las funcionalidades de Ajax seleccionan indistintamente el plug-in de Dojo o de jQuery. Los alumnos implementan una aplicacin web con Struts 2 que utiliza la etiqueta Token para evitar el problema del doble submit. Los alumnos implementan validaciones en los formularios de las aplicaciones web desarrolladas con Struts 2.
CIBERTEC
10
TEMA 1: STRUTS 2 : GESTIN DE COMPONENTES RIA.

Struts2 atiende una peticin del tipo Request de la siguiente forma: a. El Request es interpretado por el DispatcherFilter y determina que Action y que conjunto de Interceptors invocar. b. Cada Interceptor ejecuta sus acciones previas a la ejecucin del mtodo de Action a invocar Si el Interceptor I18nInterceptor intercepta el Action: Se ubicar en la session del usuario un objeto Locale para utilizar i18n. Si el Interceptor ValidationInterceptor intercepta el Action: Se ejecutan la reglas de validacin definidas sobre el Action Si el Interceptor AnnotationValidationInterceptor intercepta el Action: Se chequea en el mtodo a invocar del Action si tiene la anotacin @SkipValidation, en cuyo caso no se realizan validaciones
c. Es ejecutado el mtodo anotado con @Before en el Action d. Es invocado el mtodo del Action. e. Es ejecutado el mtodo anotado con @After en el Action f. Es ejecutado el mtodo anotado con @BeforeResult en el Action g. Cada Interceptor ejecuta sus acciones posteriores a la ejecucin del mtodo de Action a invocar Si el Interceptor ModelDrivenIntercept or intercepta el Action: Luego de la ejecucin del Action se ubicara en el value stack el modelo que provee el Action. Si el Interceptor ParametersIntercepto r intercepta el Action: Los parametros provenientes del Request se ubican en el value stack
h. Se examina el resultado obtenido del Action y se determina el Result correspondiente. i. Mediante el Result determinado se genera la vista, y segn la configuracin definida sobre l se invoca el proceso de generacin de la vista. j. La vista generada retorna al cliente.
CIBERTEC
11
1.1 ETIQUETAS AJAX Y STRUTS 2 Consultando la Wikipedia: Ajax, acrnimo de Asynchronous JavaScript And XML (JavaScript asncrono y XML), es una tcnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicacin asncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las pginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Ajax es una tecnologa asncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualizacin ni el comportamiento de la pgina. JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asncrono est formateado en XML. Ajax es una tcnica vlida para mltiples plataformas y utilizable en muchos sistemas operativos y navegadores dado que est basado en estndares abiertos como JavaScript y Document Object Model (DOM). La respuesta del servidor puede ser un formato XML, HTML, texto puro, otro Script o cualquier otro formato que el JavaScript invocador requiera.
Struts 2 soporta AJAX de dos maneras fundamentales: Cuando se devuelve un Response va Stream de datos Cuando se devuelve un Response va JSON (JavaScript Object Notation )
1.2 LIBRERA DE TAGS PARA DOJO STRUTS2: Para usar los tags de AJAX se debe: - Incluir el plugin de Dojo en el folder /WEB-INF/lib (distribuido con Struts2 ) . Agregar la taglib a cada pgina:
CIBERTEC
12
<%@taglib prefix=sx uri=/struts-dojo-tags %>

Incluir el tag <sx:head> en la pgina y configurarlo para propsitos de desempeo o de depuracin.
Muchos ejemplos se pueden encontrar en la documentacin y guas del proyecto Struts2. Los tags para manejo de funciones AJAX son: a autocompleter bind datetimepicker div head submit tabbedPanel textarea tree treenode
Tag <sx:autocompletar> Este tag es un combo box que permite autocompletar el texto ingresado en la caja de entrada. Si se emplea un action para cargar el autocompletar, la salida de dicha action debe ser en formato JSON. Este tag emplea las siguientes reglas para ubicar la fuente de datos: a) Si la respuesta en un arreglo, se asume que contiene elementos de dos dimensiones:
b) Si se especifica un valor en el atributo dataFieldName y la respuesta tiene un campo con dicho nombre, se asume que esa es la fuente de datos, la cual debe ser un arreglo de elementos de dos dimensiones o en todo caso un Map. Por ejemplo, asumiendo que datafieldName tiene el valor state:
CIBERTEC
13
O como mapa:
c) Si existe un campo que comienza con el valor especificado en el atributo name, se asume que esa es la fuente de datos. Por ejemplo, asumiendo que name tiene el valor state:
d) Se emplea el primer arreglo que se encuentra. Ejemplo:
e) Si hay un Map, se usa:
Ejemplo: Crear un action que tenga el cdigo siguiente:
CIBERTEC
14
No olvidar los getter/setter. Observe que hay una lista que se llama paises y que adems hay una variable que se llama pais. Luego, crear una pgina que utilice los tags:
Observe que: En la lnea 2 se requiere definir la taglib de Struts2 En la lnea 3 se requiere definir la tablig de los tags que se manejan con Dojo. Tambien, es importante hacer la declaracin de <sx:head /> para que se incluyan las libreras de javaScript necesarias. Luego, en la lnea 13 se utiliza el tag de autocompletar. Considere que el atributo list se asocia va OGNL con la variable pases del Action Ejemplo01 y que el atributo name se asocia a la variable pas cuando se seleccione algn pas de la lista. Si se escribe la primera letra de algn pas, debe aparecer la lista desplegable con los pases respectivos:
CIBERTEC
15
Tag <sx:datetimepicker> Este tag muestra un calendario dentro de una ventana contenedora. La sintaxis que soporta el atributo displayFormat es: Formato d D M Descripcin Da del mes Da del ao Mes: Usar M o MM para el nmero de mes. MMM para la abreviacin del mes MMMM para el nombre del mes MMMMM para el nombre ajustado. Ao Hora ( en formato de 1-12) Hora ( en formato 0-24 ) Minutos Segundos
y h H m s
Ejemplo:
CIBERTEC
16
CIBERTEC
17
Tag <sx:div> Este tag genera una marca HTML de tipo <div> que permite cargar contenido utilizando llamadas XMLHttpRequest mediante el Framework de Dojo. Cuando se coloca un valor a updateFreq, el timer interno inicia de forma automtica y recarga el contenido de la zona cada vez que se produzca el periodo de refresco ( en milisegundos ). Se pueden emplear Topics para detener (stopTimerListenTopics) o iniciar (startTimerListenTopics) el timer. Cuando se usa este tag dentro de un tabbedpanel, cada div se convierte en un tab por lo que en este caso, existen algunos atributos especficos: refreshOnShow : el contenido del div es cargado cuando se selecciona el tab. closable : el tab tiene un botn de close. preload: el contenido del div se carga inmediatamente despus que a pgina es cargada. Tag <sx:tabbedPanel> Este tag es un componente primario de AJAX, donde cada tab puede cargar contenido local o remoto ( que se refresca cada vez que el usuario selecciona el tab ). Si se coloca el valor de trae a useSelectedTabCookie, el id del tab se almacena en un cookie durante la activacin. Cuando se regresa a dicha vista, el cookie se lee y el tab se activa de nuevo. Si se desea emplear las caractersticas de cookie, se debe asegurar de proporcionar un nico id para el componente. Ejemplo:
CIBERTEC
18
Observe que en la lnea 23, el tab nmero dos tiene contenido remoto ( desde una URL ) por lo cual, los tags que estn inmersos no se mostrarn. El atributo preload indicar si dicho contenido se cargar al momento de seleccionar el tab o al momento de cargar todo el panel.
CIBERTEC
19
Tag <sx:tree> Este tag muestra un rbol con soporte AJAX. Requiere del soporte del tag <sx:treenode> Tag <sx:treenode> Muestra una hoja dentro del rbol con soporte a AJAX. Si el rbol se genera estticamente: rootNode: es el nodo padre desde donde se origina el rbol. nodeIdProperty : propiedad que permite obtener el id del nodo actual. nodeTitleProperty: propiedad para obtener el ttulo del nodo actual. childCollectionProperty: propiedad que retorna los nodos hijos del nodo actual.
CIBERTEC
20
Observe que el anidamiento de los tags <sx:treenode > indica la jerarqua dentro del rbol.
Si el rbol se genera dinmicamente: id : es el id del nodo title: es la etiqueta a ser mostrada en el nodo
Ejemplo de tree dinmico:
CIBERTEC
21
Crear una clase auxiliar:
No olvidar los getter/Setter. Observe que es una clase simple. Crear un Action :
Observe que esta clase no tiene getter/setter y se apoya en la clase auxiliar definida en el paso anterior. Ahora se genera la pgina JSP:
CIBERTEC
22
CIBERTEC
23
1.3 LIBRERA DE TAGS PARA JQUERY STRUTS2: Para obtener el plug-in se debe ingresar a Google Code en la ruta siguiente http://code.google.com/p/struts2-jquery/ y descargar los .jar necesarios de la zona ubicada al lado derecho de la pgina ( como se muestra en el grfico ).
Luego proceder a importar el .jar dentro del proyecto.
Plug-in de jQuery
Para usar los tags de AJAX se debe: Incluir el plugin de jQuery en el folder /WEB-INF/lib (como se muestra en la imagen anterior ) . Agregar la taglib a cada pgina:
<%@taglib prefix=sj uri=/struts-jquery-tags %>

Incluir el tag <sj:head> en la pgina.
Muchos ejemplos se pueden encontrar en la documentacin de Google Code. Los tags para manejo de funciones AJAX son: TabbedPanel
CIBERTEC
24
Datepicker Dialog Accordion Autocompleter Button Buttonset Progressbar Slider Grid Richtext Editor Charts Spinner
Tag <sj:autocompletar> Este tag genera un campo de tipo autocompletar que puede cargar contenido via JSON o manejar una lista. Para personalizar los temas se debe ver la documentacin del tah <sj:head>. Ejemplo: Generar una clase Action que maneje una lista de pases:
No olvidar los getter/setter. Ahora, genere una pgina JSP que haga uso del tag para mostrar la lista de pases:
CIBERTEC
25
Observe que: En la lnea 2 se requiere definir la taglib de Struts2. En la lnea 3 se requiere definir la tablig de los tags que se manejan con jQuery. Tambien, es importante hacer la declaracin de <sj:head /> para que se incluyan las libreras de javascript necesarias. Luego, en la lnea 13 se utiliza el tag de autocompletar. Considere que el atributo list se asocia va OGNL con la variable paises del Action Ejemplo01 y que el atributo name se asocia a la variable pais cuando se seleccione algun pas de la lista.
Si se escribe la primera letra de algun pas, debe aparecer la lista desplegable con los nombres de pases que contienen dicha letra:
ACTIVIDAD: Cambiar el theme para ver como se altera la apariencia de la caja. El tema se cambia en la zona <sj:head> de la pgina.
CIBERTEC
26
Tag <sj:datepicker> Este tag sirve para mostrar un calendario. Requiere que se agrega la librera commons-lang.2.3jar para evitar errores de ClassNotFoundException al momento de ejecutar el ejemplo. Tenga en cuenta que se coloca atributos de theme y locale en la zona de cabecera.
El ejemplo est tomado de la pgina de documentacin de Google (ver referencia).
CIBERTEC
27
ACTIVIDAD: Pruebe cambiar los themes en la cabecera de la pgina para observar cmo se visualizan los calendarios.
CIBERTEC
28
Tag <sj:tabbedpanel> Este tag genera un panel con varias hojas que pueden cargar contenido va invocaciones Ajax. Ejemplo: Generar una pgina JSP que emplee dicho tag:
Completar los tags faltantes al final de la pgina. Probar
CIBERTEC
29
ACTIVIDAD: Generar un tab con contenido remoto. Este ste caso usamos el atributo selectedTab teniendo en cuenta que los tabs se numeran desde cero.
CIBERTEC
30
TEMA 2: TPICOS DE SEGURIDAD Y VALIDACIN EN STRUTS 2

2.1 ETIQUETA <s:token> Struts 2 proporciona el soporte necesario para evitar el doble submit de un formulario al incorporar un tag personalizado en las pginas web y un interceptor que previene los requests duplicados. Struts 2 emplea la siguiente lgica para evitar el procesamiento de requests duplicados: a) Se codifica la pgina web con un token embebido como campo oculto. b) Se coloca dicho token nico dentro de la sesin del usuario. c) Se enva la pgina al navegador del usuario. d) Cuando el formulario es enviado, los dos tokens son comparados. e) Si los tokens no son idnticos, se retorna el resultado invalid.token. Ejemplo:
La lnea 5 introduce un nuevo tag de Struts2 llamado <s:token>, el cual se va a encargar de evitar que la pgina ejecute un doble submit. Para manejar el request, se debe declarar un interceptor. Los interceptores interrumpen la ejecucin del request y proporcionan el manejo necesario antes que se ejecute el cdigo correspondiente a la accin. El el struts.xml se registra la accin y se debe declarar el interceptor token (por defecto no est dentro del defaultStack) y los posibles resultados:
Observe que el Action est haciendo referencia al interceptor llamado token y al defaultStack (lneas con el tag <interceptor-ref> del listado). Si todo est bien, se invoca a la pgina plantilla-fin.jsp.
CIBERTEC
31
Si hay errores de validacin se invoca nuevamente a la pgina plantillainicio.jsp. Finalmente, si se ejecuta un doble submit, el interceptor invocar a la pgina plantilla-invalidtoken.jsp.
Si el usuario ejecuta el submit y luego presiona el botn de back para ejecutar un nuevo submit, se debe mostrar la siguiente pantalla:
Una solucin ms transparente para el problema del doble submit es el uso del interceptor tokenSession, el cual maneja una lgica un poco ms inteligente: en lugar
CIBERTEC
32
de devolver el invalid.token, bloquea el request duplicado y devuelve la respuesta del primer request. Para ello, debe declararse el interceptor de la siguiente forma:
2.2 VALIDACIONES EN STRUTS 2
Struts 2 proporciona dos Interfaces (implementadas por ActionSupport) framework:
en el
Validateable : que contiene un nico mtodo cuya firma es void validate(). La clase ActionSupport contiene una implementacin por defecto que permite validar mediante configuraciones basadas en XML o en anotaciones. ValidationAware: proporciona un grupo de mtodos usados para recolectar mensajes de error relacionados a campos del formulario o propiedades de la clase Action en general. Tambien se emplea para recolectar mensajes informativos y determinar si se presentan errores.
Las dos interfaces colaboran dentro del workflow de Struts2, especficamente en el stack de interceptores: interceptor validation e interceptor workflow. Si la validacin es satisfactoria, se ejecuta el mtodo respectivo de la clase Action invocada. En caso que la validacin falle, se retorna el resultado denominado input. Si no se define el resultado para input, el framework genera un error durante la ejecucin. En el siguiente grfico se muestra la arquitectura de validacin de Struts 2, la cual est conformada por tres componentes principales: Datos: (domain data) que son las propiedades que residen en el Action de Struts 2 y que se cargan cuando comienza la ejecucin de la accin. Metadata de validacin: que sirve para asociar cada propiedad con las validaciones necesarias a ser realizadas en tiempo de ejecucin. El framework permite que se utilice un archivo XML o anotaciones java. Validadores: Un validador es un componente reutilizable que contiene la lgica para ejecutar la validacin.
CIBERTEC
33
2.2.1 VALIDACIN MANUAL Implementar el mtodo void validate() en una clase Action. Generar un formulario: ejemplo01.jsp
CIBERTEC
34
Observe que el formulario llama a un action ( que debe estar registrado en el struts.xml ) Adems observe que entre las lneas #11 a la #15 hay un IF que muestra los mensajes de error ( si es que hubieran ). Estos mensajes son colocados por la validacin realizada en el Action.
CIBERTEC
35
Ahora, escribir la clase Action ( no olvidar los getter/setter de las variables ):
Ejecutar la aplicacin:
CIBERTEC
36
Si se presiona el botn Registrarse sin haber ingresado ningn dato, debe salir la siguiente pantalla (mostrando el mensaje de validacin):
Observe el mensaje debajo del campo que se ha validado. Una vez solucionado el problema, presionamos nuevamente el botn Registrarse y la aplicacin debera seguir su curso normal. 2.2.2 VALIDACION USANDO XML Una validacin ms compleja utilizando las facilidades que nos brinda el framework de Struts-2. Crear una pgina JSP similar al caso anterior.
CIBERTEC
37
Escribir la clase Action pero sin el mtodo validate del ejemplo anterior (no olvidar los getter/setter):
Escribir las validaciones de los campos nombre y apellido. Para ello se debe crear un archivo XML a la misma altura en donde est definido el Action. El nombre del archivo debe seguir la norma:
<Nombre del Action>-validation.xml

En este caso sera Ejemplo2-validation.xml cuyo contenido es:
CIBERTEC
38
Este archivo tiene dos formas de validacin: Usando <validator>: observe que el nombre del campo a validar se pasa como parmetro. Usando <field>: observe que el nombre del campo se asigna directamente en el atributo name. Cuando las validaciones son muy simples, no interesa cual de las dos formas se utilice, pero a medida que las validaciones se hacen ms complejas, es preferible emplear la forma field que hace mucho ms entendible la lectura del archivo.
2.2.3 VALIDACIONES MS COMPLEJAS CON XML Sobre la base del ejemplo anterior, se har un poco ms complejo el contenido del archivo XML de validaciones. El action es bastante sencillo ( no olvidar los getter/setter):
CIBERTEC
39
La parte importante de este ejemplo es el archivo de validacin XML que utiliza ste Action:
Note que ahora se utiliza el formato <field> para validar dos cosas: Que se ingrese un texto en el campo nombre Que el texto ingresado cumpla con una longitud mnima. Observe que se pasa como parmetro minLength y que en el texto del mensaje se puede emplear expresiones de OGNL para recuperar valores que se encuentran en el stack.
CIBERTEC
40
2.2.4 VALIDACIONES USANDO ARCHIVO .properties En este ejemplo, los textos de los mensajes se tomarn desde un archivo .properties (considerar que lo mismo sirve para i18N ). Crear una clase Action (no olvidar los getter/setter ):
Configurar el archivo de validacin: Ejemplo4-validation.xml
CIBERTEC
41
Y generar un archivo .properties a nivel de PAQUETE:
Cuyo contenido es:
Note que el texto tiene expresiones OGNL que referencian a parmetros propios del archivo de validacin. El resultado es similar a la siguiente pantalla:
CIBERTEC
42
2.2.5: VALIDACIONES DISPONIBLES EN STRUTS-2 requiredstring: Tiene un parmetro adicional que es trim el cual por defecto es TRUE. La particularidad de este parmetro es que slo ejecuta el TRIM para efectos de verificacin de la longitud, ms no para enviar el valor al Action (OJO con esto). stringlength: Tiene parmetros como trim, maxlength, minlength. En el caso del trim, se comporta igual que en requiredstring. Ejemplo:
CIBERTEC
43
int: Tiene como parmetros min y max. Si se especifican los dos parmetros, el framework verifica que el valor ingresado est dentro del rango ( intervalo cerrado ). double: Permite comparaciones de rango que incluyen o no a los extremos. Tiene como parmetros a: minInclusive, maxInclusive, minExclusive, maxExclusive en donde cualquier combinacin es permitida. email: Es una subclase del validador regex y permite validar la sintaxis de una direccin de correo electrnico. url: A diferencia del validador email, este validador no es una subclase de regex. Al contrario, utiliza las caractersticas del constructor de java.net.URL para verificar la sintaxis de una direccin URL. date: Tiene los parmetros min y max para validar rangos de fechas. Recordar que el servidor recibe los parmetros en formato STRING. regex: Este validador acepta expresiones regulares (en sintaxis Java) y valida el valor ingresado contra la expresin dada. Si el campo a ser validado es obligatorio se debe usar el validador requiredstring. Este validador acepta parmetros trim, caseSensitive cuyo valor por defecto es TRUE. expression y fieldexpression: Ambos validadores toman expresiones OGNL en el parmetro expression para evaluarlo y determinar si hubo xito o falla.
CIBERTEC
44
Se recomienda realizar evaluaciones ms complejas dentro del mtodo validate() antes que en el archivo validation.xml. Se puede combinar la validacin en el cdigo con el archivo XML simplemente invocando a : super.validate(). Ejemplo:
2.2.6: VALIDACION USANDO ANOTACIONES Tambin se puede utilizar las validaciones va anotaciones en el cdigo Java. Estos validadores requiere obligatoriamente el atributo message aun y cuando se especifique el atributo key. El parmetro message es utilizado como mensaje por defecto si es que la key no puede ser ubicada en el archivo de recursos. Adicionalmente, las expresiones OGNL estn disponibles para las anotaciones. @Validation Se puede ubicar a nivel de mtodo o a nivel de setter de una propiedad. Es una anotacin que se utiliza sin parmetros. Sola ser obligatoria, pero ya no es necesario. @Validations Se aplica a nivel de mtodo y permite agrupar las validaciones. Los grupos disponibles son: requiredFields requiredStrings intRangeFields stringLengthFields regexFields emails urls dateRangeFields expressions fieldExpressions customValidators visitorFields Esta anotacin no es especfica por mtodo. Esto significa que todas las validaciones son ejecutadas para todos los mtodos de la clase Action. Ejemplo:
CIBERTEC
45
@SkipValidation Esta anotacin sirve para marcar los mtodos que deben ser excludos de la validacin. @RequiredFieldValidator Es equivalente al validador required. Es obligatorio el ingreso del atributo message aun y cuando se haya colocado un valor al atributo key. @IntRangeFieldValidator Funciona de la misma forma que el validador int utilizado en XML. Soporta los valores de max y min. Otros validadores El comportamiento es similar a los validadores usados en XML. La documentacin del framework porporciona mayor detalle: @DoubleRangeFieldValidator @EmailValidator @UrlValidator @DateRangeFieldValidator @StringRegexValidator @ExpressionValidator @FieldExpressionValidator @ConversionErrorFieldValidator @VisitorFieldValidator
CIBERTEC
46
Resumen
Recordar que Struts 2 es un framework bastante potente que permite agregar funcionalidad de tipo Ajax mediante la incorporacin de algunos tags proporcionados por algn plug-in que trabaje con libreras de JavaScript como por ejemplo Dojo o JQuery. Tambin, Struts 2 proporciona mecanismos para bloquear el envo duplicado de formularios de captura de datos mediante el empleo del tag <s:token>. Struts 2 permite definir validaciones para los campos de captura de los formularios. Si desea profundizar estos temas, puede consultar las siguientes pginas. http://struts.apache.org/2.2.1/docs/ajax-tags.html Aqu hallar la lista completa de tags Ajax en Struts 2 y ejemplos de uso. http://code.google.com/p/struts2-jquery/ En esta pgina, hallar el plug-in de jQuery para Struts 2 as como la documentacin y ejemplos propocionados por Google Code. http://dojotoolkit.org/ En esta pgina, hallar documentacin sobre el framework Dojo Toolkit. http://jquery.com/ En esta pgina, hallar documentacin sobre el framework JavaScript JQuery.
CIBERTEC
47
JAVA PERSISTENCE API ( JPA )

Al trmino de la unidad, el alumno, construye una aplicacin web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible.
TEMARIO
Tema 1: Introduccin a la API de Persistencia 1.1 Entidad 1.2 Metadata 1.3 EntityManager 1.4 Unidad de Persistencia 1.5 Operaciones bsicas 1.6 Transacciones 1.7 Ciclo de Vida de una Entidad
Los alumnos descargan y configuran un entorno de desarrollo con las libreras de JPA. Los alumnos configurar un servidor de aplicaciones para que ejecute aplicaciones que manejan JPA. Las alumnos desarrollan aplicaciones Java Stand-Alone que trabajen con JPA para familiarizarse con el framework.
CIBERTEC
48
TEMA 1: INTRODUCCIN A LA API DE PERSISTENCIA.

La tcnica que permite acortar las diferencias entre el modelo relacional y el modelo de objetos se conoce como ORM ( Mapeo Relacional a Objetos ). La idea bsica se sustenta en que para mapear los conceptos de un modelo al otro ( o viceversa ) se requiere de un mediador que maneje de forma automtica la transformacin. La historia de JPA se origina en dos frameworks de persistencia bastante utilizados: en el lado propietario exista TopLink mientras que en el lado open estaba Hibernate. JPA es una especificacin basada en el JSR 220 conocido como Enterprise Java Bean 3.0 (http://jcp.org/en/jsr/detail?id=220 ). Al ser una especificacin (o un conjunto de APIs) est sujeta a diversas implementaciones de diversos fabricantes. La idea principal es que sea un Framework ligero, basado en POJOs y pueda enfrentar desafos de arquitectura e integracin en aplicaciones empresariales. Algunas implementaciones de JPA : Hibernate TopLink http://www.hibernate.org/ http://www.oracle.com/technetwork/middleware/toplink/o verview/index.html
OpenJPA EclipseLink
http://openjpa.apache.org/ http://www.eclipse.org/eclipselink/
1.1 ENTIDAD El concepto de Entidad fue introducido por Peter Chen en un documento llamado The Entity-relationship model Howard a unified view of data publicado en ACM Transactions on Database Systems en el ao de 19761. En dicho documento se describa a las entidades como cosas que tenan atributos y relaciones con la expectativa de que dichos atributos y relaciones pudieran ser almacenados en la base de datos. En la actualidad dicha definicin es vigente y dado que cualquier objeto dentro de una aplicacin JPA puede ser una entidad, hay que definir las caractersticas que debe poseer una Entidad: Persistencia : las entidades pueden ser manipuladas para recuperase en memoria o ser grabadas en un almacn de datos.
Una copia del documento se puede obtener en el enlace: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.1085&rep=rep1&type=pdf
CIBERTEC
49
Identidad: significa que las entidades tienen un identificador que permite emplearlas de manera inequvoca y diferenciarlas de otras instancias de la misma entidad. El identificador de la entidad es equivalente a la llave primaria de una tabla en la base de datos. Transaccionalidad: Todas las operaciones ( insertar, modificar o eliminar ) deben realizarse dentro de un contexto transaccional debido a que se requiere de una transaccin para que los cambios sean grabados en la base de datos. Granularidad: Las entidades son objetos que pertenecen a un dominio de negocio, poseen un conjunto de estados y por tanto son relevantes para la aplicacin (no se trata de objetos con tipo primitivo, sino de objetos ms complejos).
1.2 METADATA Cada entidad tiene asociado una metadata que la describe. Dicha informacin puede estar almacenada dentro de la entidad Java o puede existir en un archivo externo: en ambos casos, esa informacin no se almacena en la base de datos. Existen dos maneras de especificar la metadata: Usando Anotaciones Usando XML
Las anotaciones fueron introducidas en la versin JAVA EE 5 y permiten que la metadata est incorporada dentro del cdigo fuente Java. El uso de las anotaciones requiere que se importe el paquete javax.persistence.* dentro de la clase Java que representa a la Entidad. El uso de XML es una opcin alternativa a las anotaciones, aunque su lectura puede resultar compleja para proyectos grandes. Un JavaBean cualquiera como el siguiente
Se puede convertir en entidad, simplemente agregndole las anotaciones : @Entity @Id
CIBERTEC
50
No se debe olvidar que al ser un JavaBean, sigue las reglas de ste (con los getter/setter).
1.3 ENTITY MANAGER La mayora de llamadas a las APIs de JPA se encapsulan dentro de lo que se conoce como Entity Manager y mediante el cual se puede alcanzar a la base de datos. Esta encapsulacin es implementada dentro de una interface conocida como EntityManager que es la que ejecuta todo el trabajo de persistencia. Por tanto, una entidad mientras que no se trabaje con el Entity Manager es un objeto Java simple como cualquier otro. Cuando el Entity manager obtiene una referencia a una Entidad, se dice que dicha entidad est en estado managed El conjunto de entidades en estado managed dentro de un Entity Manager se conoce como persistence context. Los Entity Managers son configurados para trabajar con determinados tipos de objetos, bases de datos y son implementados por un proveedor (provider) conocido como persistence provider. En trminos prcticos este provider es la implementacin de la especificacin JPA. Los Entity Managers se generan a partir de una factora de tipo EntityManagerFactory, que genera una especie de plantilla para la persistencia, pero toma la configuracin particular desde una unidad de persistencia conocida como persistence unit, la cual contiene la configuracin implcita o explcita (con un nombre asociado ) para las entidades y para el Entity Manager. El grfico2 resume las relaciones entre los conceptos mencionados:
FUENTE: JPA 2: Mastering the Java Persistence API, pg 23.
CIBERTEC
51
Un Entity Manager se obtiene de la siguiente forma: Nombre de la persistence unit Debe ser el mismo que aparece en el archivo persistence.xml
Clase esttica
Variable con el Entity Manager cargado
1.4 UNIDAD DE PERSISTENCIA La configuracin de una unidad de persistencia se escribe en un archivo llamado persistence.xml, el cual debe estar ubicado dentro del folder META-INF de un proyecto Java. Cada unidad de persistencia tiene un nombre, el cual es referenciado por la factora al momento de pedirle que genere un EntityManager. Un archivo persistence.xml puede contener una o ms unidades de persistencia, siendo cada una diferente de la otra. La estructura bsica de un archivo persistence.xml es la siguiente:
CIBERTEC
52
Debido a que es un archivo XML, debe tener un DTD:
Luego viene la definicin de la Unidad de persistencia, el proveedor y las clases Java definidas como entidades: Nombre de la persistence unit
El valor de RESOURCE_LOCAL indica que la conexin a la base de datos se realizar desde la misma aplicacin ( No emplea Pool de conexiones ). Despus se definen las propiedades de conexin a la base de datos:
CIBERTEC
53
Finalmente se cierran los tags XML:
Observe que las propiedades JDBC ( javax.persistence.jdbc.* ) han sido estandarizadas en JPA 2.0. En versiones anteriores de JPA, esas propiedades eran definidas por cada Persistence Provider. 1.5 OPERACIONES BASICAS Para aquellos desarrolladores acostumbrados al SQL en bases de datos relacionales, la equivalencia es sencilla en JPA: SQL INSERT = Mtodo Persist SQL SELECT = Mtodo Find ( o tambien puede usarse el SELECT JPQL ) SQL UPDATE = Mtodo Merge SQL DELETE = Mtodo Remove
El de una entidad significa crear un objeto en memoria y luego almacenarlo en la base de datos para recuperarlo posteriormente. Como se ha mencionado, equivale a insertar uno o ms registros en la base de datos.
persist
Se instancia el objeto Java Se cargan los valores de los atributos
Se ejecuta el mtodo persist mediante el EntityManager Si ocurre un error durante la ejecucin del persist, se lanza la excepcin PersistenceException, la cual debe ser propagada, debiendo ser manejada por el programa.
CIBERTEC
54
Para ubicar a una Entidad empleando el mtodo slo una lnea de cdigo:
find,
generalmente se requiere
Clase de la Entidad a ser ubicada Evita hacer un cast Llave primaria de la Entidad
variable con el EntityManager cargado
Si la entidad con la llave primara indicada no existe, el EntityManager devolver NULL. La aplicacin debe verificar el valor antes de usar la variable emp en el caso del ejemplo. Para eliminar una entidad se hace uso del mtodo . Sin embargo se debe tener en consideracin que para eliminar una entidad en JPA, primero debe colocarse en estado managed, es decir, debe cargarse al contexto de persistencia.
remove
Se requiere cargar la entidad
Como se mencion anteriormente, si la entidad no existe el EntityManager devolver NULL, por lo que se debe evaluar dicha condicin antes de invocar al mtodo remove. Si se enva un valor de NULL al remove, JPA lanzar la excepcin java.lang.IlegalArgumentException. Para actualizar atributos de una entidad, se emplea el mtodo requiere ubicar a la entidad antes de actualizarla:
merge.
Se
En este ejemplo se est actualizando el apellido del empleado con ID = 8.
CIBERTEC
55
1.6 TRANSACCIONES El nico mtodo que puede estar fuera de una transaccin es el find dado que no cambia atributos de las entidades. En una aplicacin Java StandAlone (Java SE), se debe invocar el contexto transaccional de forma explcita, mientras que en una aplicacin Java EE, se asume que el container proporciona dicho contexto transaccional.
Se inicia una transaccin
Se inicia finaliza la transaccin
1.7 CICLO DE VIDA DE UNA ENTIDAD JPA proporciona unos mtodos denominados callbacks ( listeners ) para ejecutar acciones en los diferentes estados que pueden suceder dentro del ciclo de vida de una entidad. Por ejemplo, imagine que desea actualizar una entidad, pero antes de hacerlo debe verificar que algunos datos estn presentes. En el grfico se puede apreciar que una entidad no existe hasta que se instancia el objeto y se graba en la base de datos. De ah pasa al estado manejado o administrado por el EntityManager y luego de ello se puede remover, actualizar, liberar ( detach ) o incluso volver a leer ( refrescar ).
CIBERTEC
56
Las anotaciones que proporciona JPA para manejar los Callbacks son: @PostLoad : Se ejecuta luego de un refresh a la entidad. @PrePersist: Se ejecuta antes de insertar la entidad. @PostPersist: Se ejecuta despus de haber insertado la entidad. @PreUpdate: Se ejecuta antes de un update a la entidad. @PostUpdate: Se ejecuta despus de un update a la entidad. @PreRemove: Se ejecuta antes de eliminar la entidad en la base de datos. @PostRemove: Se ejecuta despus de haber eliminado a la entidad.
Los mtodos callback se pueden declarar dentro de la misma entidad o tambien en una clase Java separada. Por ejemplo, si de declaran dentro de la misma entidad :
CIBERTEC
57
En cambio, si se prefiere emplear una clase Java externa, sera as: a) A la Entidad hay que agregarle la anotacin @EntityListeners para indicar cual es la clase Java que contiene los mtodos callbacks. b) Se debe crear una clase Java y escribir los mtodos que se requiere manejar (con las anotaciones del caso).
CIBERTEC
58
Resumen
Recordar que JPA es una especificacin, por tanto, tiene muchas implementaciones. El desarrollador debe seleccionar una en particular, siendo las ms conocidas: Open JPA, TopLink, EclipseLink e Hibernate. Diferenciar entre Entidades y Clases Java Recordar la ubicacin del archivo persistence.xml que debe ir siempre dentro del folder META-INF. Recordar para que sirve el EntityManager y la persistence-unit Las operaciones bsicas sobre una Entidad: find, persist, merge, remove Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas: http://www.eclipse.org/eclipselink/jpa.php Aqu hallar una referencia completa a la implementacin EclipseLink. http://www.agiledata.org/essays/mappingObjects.html Aqu hallar informacin til sobre Entidades JPA.
Tambien puede consultar el libro Pro JPA 2 : Mastering the Java API Persistence Captulos 1,2,4, y 6.
CIBERTEC
59

TEMARIO
Tema 2: OR-Mapping con JPA 2.1. Anotaciones 2.2. Manejo de la Llave Primaria 2.3. Generacin de la Llave Primaria 2.4. Llave Primaria Compuesta 2.5. Objetos Embebidos
Los alumnos escriben clases Java, las convierten en Entidades JPA y trabajan con tablas relacionales. Las alumnos desarrollan aplicaciones Java stand-alone haciendo uso de entidades JPA.
CIBERTEC
60
TEMA 2: OR-MAPPING CON JPA

2.1 ANOTACIONES Las anotaciones pueden clasificarse en dos grupos: Anotaciones lgicas describen el modelo de entidades desde el punto de vista del modelamiento orientado a objetos. Constituyen una especie de metadata del modelo. Anotaciones fsicas estn relacionadas con el modelo en la base de datos (modelo fsico) y tienen que ver con tablas, columnas, etc.
Las anotaciones dentro de una clase Java se pueden colocar a nivel de atributos o a nivel de mtodos. Si se colocan a nivel de atributos se denomina Field Access mientras que si se coloca a nivel de mtodos se denomina Property Access.
Anotacin de tipo Field Access Atributos de la clase
Es equivalente a:
Anotacin de tipo Property Access NOTA: Siempre va en el GETTER
En la especificacin de JPA 2.0 se introduce la anotacin @Access permite combinar los dos modos presentados en el ejemplo. Esta anotacin permite sobre escribir el modo de acceso por defecto, aunque no es muy usual hacerlo. Para definir una entidad basta con emplear la anotacin @Entity y la anotacin @Id.
CIBERTEC
61
Anotacin @Table Por defecto no es necesario incluir ninguna anotacin para referenciar a una tabla. JPA asume que la tabla se llama igual que la clase Java en donde se define la entidad. Sin embargo, si se desea especificar un nombre de tabla en particular para asociarlo con la entidad, es preciso utilizar la anotacin @Table con el parmetro name respectivo.
Se puede indicar adems el esquema de base de datos con el atributo schema (para aquellos motores de base de datos que lo soporten):
Se debe tener cuidado con el uso de maysculas y minsculas, pues muchos manejadores de bases de datos no son sensibles a esto. Anotacin @Basic Cuando se persiste una propiedad de una entidad, el persistente provider verifica que el tipo de dato corresponda a un tipo soportado y trata de pasarlo hacia la base de datos va el driver JDBC. Los tipos de datos soportados son: Tipos primitivos Clases que encapsulan a tipos primitivos Arreglos de bytes y caracteres Nmeros Cadenas de caracteres byte, int, short, long, boolean, char, float double Byte, Integer, Short, Long, Boolean, Character, Float, Double byte[], Byte[], char[], Character[] java.math.BigInteger, java.math.BigDecimal java.lang.String
CIBERTEC
62
Tipos de datos que manejan fechas Java Tipos de datos que manejan fecha JDBC Tipos enumerados Objetos serializables
java.util.Date, java.util.Calendar java.sql.Date, java.sql.Time, java.sql.Timestamp Cualquiera Cualquiera
Se debe tener cuidado con el comportamiento del driver JDBC cuando los tipos de datos no coinciden entre lo que se define en la entidad y lo que soporta la base de datos, pues el driver intentar ejecutar la mejor conversin posible. La anotacin @Basic (que es opcional) se utiliza para indicar de forma explcita que dicho atributo debe ser almacenado en la base de datos. Anotacin @Transient Se emplea para marcar aquellos atributos de la entidad que NO deben ser guardados en la base de datos. Anotacin @Column Es una anotacin de tipo fsico, pues indica las caractersticas fsicas de la columna en la base de datos. Si no se especifica para un atributo determinado marcado como persistente, JPA asume que la columna se llama igual que dicho atributo. En cambio, si la columna tiene un nombre diferente, se deber especificar con el uso de la anotacin @Column.
CIBERTEC
63
Los elementos que acompaan a la anotacin @Column son: Elemento Descripcin Valor por defecto
String (Opcional) columnDefinition Es el fragmento de SQL utlizado para generar el DDL de la columna (depende del manejador de base de datos) boolean (Opcional) Indica si la columna ser incluir dentro de una insertable sentencia SQL INSERT generada por el Persistence Provider. int length (Opcional) Indica la longitud de la columna en la tabla y funciona nicamente cuando la columna es un String o cadena de caracteres. String name (Opcional) Indica el nombre de la columna. POr defecto se asume que la columna se llama igual que el atributo de la entidad. boolean nullable (Opcional) Indica si la columna permite valores nulos. int precision (Opcional) Indica la precisin para una columna numrica ( vlido solo para columnas decimales ). int scale (Opcional) Indica la escala para una columna numrica ( vlido solo para columnas decimales ). String table (Opcional) Indica el nombre de la tabla en donde se asocial la columna. boolean unique (Opcional) Se emplea cuando la clave nica corresponde a una sla columna. boolean (Opcional) Indica si la columna ser incluir dentro de una updatable sentencia SQL UPDATE generada por el Persistence Provider.
true 255
true 0 0 false true
Ejemplo 1:
Ejemplo 2:
Anotacin @Lob Para el manejo de objetos binarios (imgenes o archivos generalmente) se requieren accesos especiales en el driver JDBC para efectuar conversiones entre el objeto Java y la columna en la tabla de la base de datos. La anotacin @Lob sirve para indicar que el atributo de dicha entidad requiere efectuar las conversiones va JDBC. Ahora bien, los campos LOB (acrnimo de Large Object ) se pueden clasificar de dos maneras, siendo el manejo de cada manera un tanto diferente:
CIBERTEC
64
Si el objeto es Character Large Objets ( CLOB )
El tipo java a usar es char[] Character[] String byte[] Byte[] tipos serializables
Binary Large Objects ( BLOB )
En ambos casos, el driver JDBC es responsable de hacer las conversiones entre el objeto Java y la base de datos. Ejemplo:
Anotacin
Tipo de dato
Anotacin @Temporal Sirve para especificar tipos de datos basados en el tiempo. Estos tipos de datos se pueden clasificar en dos ramas: los que vienen del paquete java.sql y los que viene del paquete java.util. En el paquete java.sql los tipos se trabajan directamente: java.sql.Date java.sql.Time java.sql.Timestamp
En cambio, en el paquete java.util: java.util.Date java.util.Calendar
CIBERTEC
65
Se debe especificar la anotacin @Temporal y adems especificar el atributo TemporalType con uno de los tres valores que representan a cada uno de los tipos java.sql (DATE, TIME o TIMESTAMP). Ejemplo:
Anotacin
Tipo de dato java.util.Date
Equivalencia JDBC
2.2 MANEJO DE LA LLAVE PRIMARIA Cada Entidad debe tener una llave primaria. La anotacin empleada es @Id sobre el atributo que contiene la llave. Adicionalmente se puede usar @Column para asociar al atributo con la columna en la tabla. Una llave primaria se asume que es insertable, pero no puede ser nullable o updatable por lo que se debe tener cuidado de no sobre escribir esos atributos salvo excepciones muy especficas (cuando se manejan relaciones). Los tipos de datos soportados para una llave primaria son: Tipos primitivos Clases de tipos primitives Cadenas de caracteres Nmeros grandes Tipos basados en tiempo byte, int, short, long, char Byte, Integer, Short, Long , Character java.lang.String java.match.BigInteger java.util.Date, java.sql.Date
2.3 GENERACION DE LA LLAVE PRIMARIA Tambin se conoce como Generacin del ID y se realiza mediante la anotacin @GeneratedValue. En base a dicha anotacin, el Persistence Provider genera el ID para cada entidad, y lo inserta en la columna respectiva. Se debe tener en cuenta que dependiendo de la estrategia de generacin del ID, el valor obtenido puede que no est disponible hasta que se ejecute un flush o un commit a la transaccin.
CIBERTEC
66
Existen cuatro estrategias posibles (que son un tipo enumerado de GenerationType): AUTO TABLE SEQUENCE IDENTITY
ESTRATEGIA GenerationType.AUTO Este tipo de estrategia delega en el Persistence Provider la seleccin de la mejor forma de generacin de los ID. Cualquiera sea la la forma elegida por el provider, se confiar en los recursos de la base de datos para la obtencin de los IDs. En el caso particular de EclipseLink con MySQL, la estrategia AUTO emplea una tabla denominada sequence. Ejemplo:
ESTRATEGIA GenerationType.TABLE Esta estrategia es la ms flexible y portable, pues permite que la aplicacin genere IDs diferentes de acuerdo a las necesidades. La tabla requiere de dos columnas, una conteniendo el identificador para generar la secuencia y la otra columna contiene el ltimo valor generado. Cada fila de la tabla es un generador diferente para los IDs. Un ejemplo sencillo es el siguiente:
CIBERTEC
67
Dado que no se ha especificado el nombre de un generador ni el nombre de una tabla, el Persistence provider seleccionar sus propios valores. Lo ms comn es que busque (la tabla debe existir en la base de datos ) una tabla como la indicada en la figura. Qu sucede si se desea especificar una tabla en particular ? Se debe emplear la anotacin @TableGenerator. Ejemplo:
El atributo allocationSize indica el incremento en la generacin del ID ( para el caso del ejemplo va de uno en uno ). Por defecto el incremento es 50.
CIBERTEC
68
ESTRATEGIA GenerationType.SEQUENCE Esta estrategia depende de las capacidades de la base de datos para manejar objetos de tipo secuencia (caso de Oracle ). Al igual que en la estrategia TABLE, basta con escribir la anotacin para que el Persistence Provider seleccione la mejor secuencia dentro de la base de datos. Ejemplo:
Estrategia
Si se desea especificar una secuencia en particular, debe indicarse el generator y la anotacin @SequenceGenerator. Se debe considerar que la secuencia debe existir previamente en la base de datos ( salvo que la opcin de generacin de DDL est habilitada en nuestra aplicacin). Ejemplo (la secuencia es para Oracle) :
CIBERTEC
69
ESTRATEGIA GenerationType.IDENTITY Esta estrategia aprovecha las facilidades de la bases de datos para utilizar columnas de tipo autoincremento. Sin embargo es menos eficiente porque el identificador generado no est disponible hasta despus que ocurra el INSERT. No requiere una anotacin para el generador dado que el campo autoincremental es parte de la definicin de la tabla que corresponde a la entidad. Ejemplo :
Estrategia
2.4 LLAVE PRIMARIA COMPUESTA En algunas situaciones, en donde se requiere que la llave primaria de una entidad est compuesta de mltiples atributos. JPA proporciona dos formas de soportar esta necesidad mediante las anotaciones: @IdClass @EmbeddedId Se debe tener en cuenta que: a) En ambos casos se requiere de una clase Java externa que sea la que maneje los atributos de la llave primaria. b) La clase Java que maneja los atributos de la llave primaria, debe implementar los mtodos equals() y hashCode() con el fin que el Persistence Manager pueda almacenar e identificar las entidades. c) La clase Java que representa a la llave primaria debe ser pblica, implementar a la interface Serializable y tener un constructor sin argumento. Ejemplo: Dada la siguiente tabla tbmatricula con una llave primaria compuesta
CIBERTEC
70
La Entidad y la clase Java que maneja la llave primaria pueden representarse as (no olvidar que se debe generar los mtodos getter/setter en ambas clases Java):
Observe que la anotacin @IdClass especifica el nombre de la clase Java que maneja la llave primaria.
CIBERTEC
71
Observe tambien que la clase Java que maneja la llave primaria no posee anotaciones. Sin embargo, debe implementar los mtodos nombrados lneas arriba:
El mtodo equals() lo que hace es comparar uno a uno los atributos de la llave primaria contra los atributos de otra entidad para verificar que no se trate de la misma entidad. El mtodo hashCode() lo que hace es devolver un cdigo hash de los valores de la llave primaria. Para consultar una entidad con una llave primaria compuesta slo se requiere generar una instancia de la clase que maneja la llave primaria, cargarle los valores necesarios y pasar dicha variable al EntityManager. Ejemplo:
2.5 OBJETOS EMBEBIDOS Un objeto embebido es aquel que es dependiente de una entidad: no tiene identidad por s mismo. Entender este concepto es muy til para el manejo de relaciones entre entidades.
CIBERTEC
72
Si bien, a nivel de Java, los objetos embebidos se administran de forma separada, a nivel de base de datos, la entidad y la clase embebida se almacenan sobre el mismo registro de la tabla. Por ejemplo, en el siguiente grfico se tiene la entidad CUSTOMER y la tabla tbcustomer. Observe que los datos de la direccin pueden constituir una clase separada:
Si se convierte la direccin en una clase Embebida quedara as:
Anotacin @Embeddable
Anotacin @Embedded
CIBERTEC
73
Se debe observar que : a) La Entidad declara un atributo con el tipo de dato de la clase Address y a este atributo le coloca la anotacin @Embedded para indicar que esa clase es embebida. b) La clase Address NO tiene anotaciones que indiquen que es una entidad. Unicamente tiene la anotacin @Embeddable para indicar que hay otra clase que la incluye (o que la referencia). c) Ambas clases tienen sus getter/setter. d) Ambas clases deben definirse en el archivo persistente.xml. e) Finalmente, es importante saber que slo se puede ejecutar queries sobre la clase marcada como Entidad.
CIBERTEC
74
Resumen
Una clase Java se convierte en Entidad al agregar la anotacin @Entity. Adems, existen otras anotaciones que permiten el mapeo contra columnas de la tabla en la base de datos. Existen cuatro maneras de generar la secuencias para IDs: AUTO TABLE SEQUENCE IDENTITY
Recordar el uso de la anotacin @Temporal para tipos de datos que manejan tiempo. Revise el libro :Pro JPA 2 : Mastering the Java API Persistence Captulo 4 Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. http://www.objectdb.com/api/java/jpa/annotations/orm Aqu hallar mayor informacin respecto al tema.
ACTIVIDAD RECOMENDADA Buscar mayor informacin sobre la anotacin @Access Investigar acerca de tipos enumerados que se manejan con @Enumerated
CIBERTEC
75

TEMARIO
Tema 3: Relaciones entre entidades 3.1. Conceptos bsicos 3.2. Many To One 3.3. One to One 3.4. Bidireccionalidad de la relacin One-to-One 3.5. One to Many 3.6. Many to Many 3.7. Opciones de Fetch
Los alumnos generan Entidades JPA y definen relaciones entre ellas. Las alumnos desarrollan aplicaciones Java haciendo uso de las entidades JPA y sus relaciones.
CIBERTEC
76
TEMA 3: RELACIONES ENTRE ENTIDADES

3.1 CONCEPTOS BSICOS
ROLES Las relaciones entre entidades tienen tres diferentes perspectivas: a) La primera es el punto de vista desde un lado de la relacin. b) La segunda en el punto de vista desde el otro lado de la relacin. c) La tercera es la perspectiva global que mira ambos lados de la relacin. Estos lados son conocidos como roles. Tal es as que en cada relacin hay dos entidades que se relacionan mutuamente de tal manera que cada una cumple un rol dentro de la relacin. Es ms, una entidad puede jugar muchos roles dentro de un modelo.
DIRECCIONALIDAD Existe maneras de crear, remover y actualizar las relaciones para darles mantenimiento. Si una entidad tiene relacin con otra, existir un atributo que sirve para identificar la relacin y referirse a la entidad relacionada identificando as el rol que juega en la relacin. Cuando las entidades se referencian mutuamente se dice que la relacin es bidireccional. Ejemplo: El empleado sabe en que Proyecto trabaja y el Proyecto conoce quines son sus miembros (las flechas indican el sentido de la direccin).
Si una entidad apunta nicamente a otra, la relacin es unidireccional. El empleado conoce su Direccin, pero la inversa no necesariamente es cierta ( la flecha indica el sentido de la relacin).
Ahora bien, la relacin Bi-direccional puede ser descompuesta en dos relaciones unidireccionales. Cada relacin tendr un origen (source o rol de referencia) y un
CIBERTEC
77
destino ( target o rol referido ). Se debe tener en cuenta esto, pues el origen y destino varan segn la perspectiva que estemos usando para analizar la relacin.
CARDINALIDAD La cardinalidad de una relacin sirve para determinar cuantas instancias de una entidad existen en cada lado de una misma relacin. Cada rol dentro de la relacin tendr su propia cardinalidad, la cual indicar cuando exista una sola o muchas instancias. Por ejemplo, muchos empleados pueden trabajar en el mismo departamento (se muestra una relacin de muchos a uno):
ORDINALIDAD Un rol puede especificarse de forma ms detallada para indicar si puede o no estar presente en una relacin. La ordinalidad sirve para indicar si la entidad target necesita ser especificada cuando la entidad source es creada. Debido a que la ordinalidad es un valor lgico (verdadero o falso) es ms prctico referirse a ella como opcionalidad de la relacin.
MAPEANDO LA RELACIN ENTRE ENTIDADES Existen bsicamente dos formas de asociacin: Las basadas en valores simples. Las basadas en colecciones de valores.
Dentro de esas formas de asociacin, existen cuatro formas de mapeo: Relacin One-To-One (valores simples) Relacin Many-To-One (valores simples) Relacin One-To-Many (colecciones de valores) Relacin Many-To-Many (colecciones de valores)
CIBERTEC
78
A nivel de Base de Datos, la relacin entre entidades significa que una tabla referencia a otra tabla: aparece el concepto de Foreign Key para indicar aquellos campos de una tabla que hacen referencia a la Primary Key de otra tabla. A nivel de JPA las columnas que forman la Foreign Key se conocen como Join Columns y emplean la anotacin @JoinColumn para indicar dicha funcionalidad.
3.2 RELACIN MANY-TO-ONE Es la relacin ms tpica que podemos encontrar en el mundo real. En UML se requiere que la clase source tenga un atributo del tipo de la clase target para poder navegar hacia ella. Ejemplo: Si varios Empleados pueden trabajar en un Departamento, la relacin de entidades se puede modela como se muestra a continuacin:
Tenga en cuenta que: a) La clase source tienen un atributo que corresponde al tipo de la clase target (observe el atributo departamento). b) A dicho atributo se le debe colocar la anotacin @ManyToOne. Ahora falta llevar la relacin al modelo de base de datos siguiente:
CIBERTEC
79
Las tablas fsicas estn relacionadas mediante la columna DPTO_ID en la tabla tbempleado que apunta a la columna DEPT_ID en la tabla tbdepartamento. Entonces, la Join Column de la relacin es la columna DPTO_ID. El lado que tiene a la Join Column se conoce como el OWNER SIDE de la relacin, mientras que el lado que no tiene a la Join Column se conoce como INVERSE SIDE. En este ejemplo, el lado OWNER es la tabla tbempleado y el lado INVERSO es la tabla tbdepartamento. La anotacin @JoinColumn siempre se debe colocar en el lado OWNER de la relacin. La entidad Employee debe quedar as (observe la anotacin @JoinColumn):
CIBERTEC
80
Si no se coloca la anotacin @JoinColumn, JPA asume el nombre por defecto, el cual est formado por el nombre del atributo en la entidad owner seguido de un guin bajo (_ ) y concatenado con el nombre de la columna PK en la tabla inversa.
3.3 RELACIN ONE-TO-ONE La relacin Uno a Uno es casi igual a la relacin Muchos a Uno con la sola excepcin que una instancia de la entidad source puede apuntar a una nica instancia de la entidad target. Estrictamente hablando, eso significa que la entidad target no puede ser compartida por otras instancias de la entidad source.
A nivel de base de datos esta relacin implica un criterio de unicidad o llave nica en la Foreign Key de la entidad source.
Obviamente se requiere definir la relacin en la Entidad Employee: para ello se hace uso de la anotacin @OneToOne y tambin se requiere usar @JoinColumn (en este caso, la columna de Join es PARKING_ID). La entidad Employee quedar as:
CIBERTEC
81
3.4 BIDIRECCIONALIDAD DE LA RELACIN ONE-TO-ONE En algunas situaciones se requiere considerar la relacin inversa entre las entidades, tambin conocida como bidireccionalidad de la relacin. La decisin es un criterio de modelamiento, ms no una obligacin a nivel de programacin. Para lograr esto, se requiere que la entidad target tenga un atributo de la clase correspondiente a la entidad source. Dicho atributo debe tener la anotacin @OneToOne con el elemento mappedBy que indique cual es el atributo de la clase source que contiene la relacin y apunta a la entidad target. Ejemplo: en el caso de la entidad ParkingSpace (es el target de la relacin) se tendra el siguiente atributo:
Y en el caso de la entidad Employee ( que es el owner de la relacin) tendramos:
Debe tenerse en cuenta dos reglas:
CIBERTEC
82
a) La anotacin @JoinColumn se coloca en la entidad que mapea a la tabla que contiene la columna de join ( o a la entidad que es owner de la relacin ). b) El elemento mappedBy debe colocarse a la anotacin @OneToOne de la entidad inversa o target de la relacin.
3.5 RELACIN ONE-TO-MANY Cuando una entidad se asocia con una coleccin de otras entidades estamos ante una relacin de uno a muchos. En el ejemplo del Empleado vs. el Departamento, la relacin es bidireccional por naturaleza. En una relacin bidireccional, siempre existen dos mapeos: uno por cada relacin. A nivel de base de datos, la tablas siguen siendo las mismas.
Y a nivel de entidades, la entidad Employee es la misma. Como se tiene que implementar el lado inverso de la relacin entre Empleado y Departamento, se debe modificar la entidad Department para agregar la relacin inversa One-To-Many: se debe mapear una coleccin de entidades Empleado usando la anotacin @OneToMany. Adicionalmente, como ste es el lado inverso de la relacin, se debe usar el atributo mappedBy para indicar cual es el atributo dentro de la entidad Employee que contiene la llave de la relacin:
CIBERTEC
83
NOTA: En este caso se est usando una coleccin indicado el tipo de los elementos que almacena dicha coleccin: Collection<Type>. Esto genera una dependencia al compilar por lo que no es recomendable.
La otra forma de colocar la relacin es especificando el atributo targetEntity sin especificar el tipo de dato contenido en la coleccin:
Esquemticamente las dos relaciones se ven as:
CIBERTEC
84
Es importante tener en cuenta que: a) El lado many-to-one siempre es el lado owner de la relacin. En consecuencia, la anotacin @JoinColumn debe estar en dicho lado. b) El lado one-to-many es el lado inverso, por lo que el elemento mappedBy debe ser utilizado en este lado. c) Si no se especifica el mappedBy, JPA considera que es una relacin unidireccional de tipo one-to-many por lo que requiere el uso de una tabla de Join. Tener en cuenta que esto puede ocasionar errores al desarrollar aplicaciones.
3.6 RELACIN MANY-TO-MANY Cuando una o ms entidades se asocian con una coleccin de otras entidades y dichas entidades tienen relaciones sobrepuestas con las mismas entidades target, se dice que estamos frente a una relacin de tipo Mucho-a-Muchos. Por ejemplo: Un Empleado pueden trabajar en mltiples Proyectos y cada Proyecto puede tener a muchos Empleados. De los ejemplos anteriores podemos manejar las siguientes entidades:
CIBERTEC
85
La relacin Muchos-a-Muchos se puede expresar en las dos entidades (source y target) utilizando la anotacin @ManyToMany. teniendo en cuenta que: a) Cuando la relacin Many-To-Many es bidireccional, ambos lados de la relacin deben tener la anotacin @ManyToMany. b) No existen columnas de join en cada lado de la relacin: la nica forma de implementar sta relacin es utilizando una tabla de join, por lo que no existe manera de determinar CUAL es el lado owner de la relacin, en consecuencia, se debe asumir que uno de los lados es el owner. c) Al igual que en las relaciones bidireccionales anteriormente tratadas, el lado que no sea owner debe utilizar el mapeddBy, en caso se omita ste elemento, JPA deducir que se trata de dos relaciones unidireccionales separadas. En el ejemplo, la anotacin @ManyToMany debe colocarse en ambas entidades:
CIBERTEC
86
El modelo de base de datos es:
A nivel de base de datos, una Join Table consiste simplemente de dos Foreign Key o columnas de join que referencian (cada una) a un lado de la relacin. La anotacin @JoinTable se usa para configurar la tabla de join de la relacin: a) Cada columna de Join se distingue dependiendo del papel dentro de la relacin: lado owner o lado inverso. b) La columna de Join que pertenece al lado owner se describe usando el elemento joinColumns. c) La columna de Join que pertenece al lado inverse se describe usando el elemento inverseJoinColumns.
En el ejemplo, falta indicar la JoinTable de la siguiente forma (asumiendo que Employee es el owner de la relacin).
Tenga en cuenta que el elemento name dentro de @JoinColumn especifica el nombre de la columna en la tabla de Join, mientras que el elemento
CIBERTEC
87
referencedColumnName indica la columna que es Primary Key en la tabla que se encuentra al extremo de la relacin ( sea owner o inversa). Y en el lado inverso de la relacin se pone el elemento mappedBy:
3.7 OPCIONES DE FETCH Las entidades y sus atributos pueden ser cargados de dos formas: LAZY: Cuando se cargan de forma perezosa, es decir, se cargan en el momento en que se requieren. EAGER: Cuando se cargan de forma proactiva, es decir, al momento de cargar la entidad owner de la relacin.
En trminos de JPA, se usa el elemento fetch acompaando a la anotacin de la relacin e indicando el valor de FetchType.LAZY o FetchType.EAGER . En una relacin de valores simples el FetchType por defecto es EAGER. En una relacin de colecciones de valores, el FetchType por defecto es LAZY. En una relacin bidireccional, el FetchType puede ser EAGER en un sentido y LAZY en el otro dependiendo del tipo de navegacin que se desea.
CIBERTEC
88
Resumen
Recordar que en JPA, existen cuatro tipos de relaciones entre entidades: One To One One To Many Many To One Many To Many
Revise el libro :Pro JPA 2 : Mastering the Java API Persistence Captulo 4 Si desea profundizar ms acerca de este tema, puede consultar el siguiente enlace: http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa2.html Aqu hallar un ejemplo desarrollado del tema.
CIBERTEC
89

TEMARIO
Tema 4: Lenguaje de Consultas JPQL 4.1. Introduccin a JP-QL 4.2. Consultas dinmicas 4.3. Consultas nombradas 4.4. Uso de parmetros 4.5 Ejecucion de Queries 4.6 Sintaxis de JPQL
Las alumnos desarrollan aplicaciones web que mediante el empleo de JPQL naveguen en la base de datos utilizando el modelo de entidades JPA y sus relaciones.
CIBERTEC
90
TEMA 4: LENGUAJE DE CONSULTAS JPQL

JPA soporta dos formas para expresar consultas que recuperan entidades desde una base de datos: El lenguaje de consultas (queries), conocido como Java Persistence Query language ( JPQL ), es un lenguaje independiente del manejador de base de datos que trabaja con entidades en lugar de usar tablas. La API de criterios, que sirve para construir consultas basadas en objetos Java en lugar de escribir los queries en strings.
4.1 INTRODUCCIN A JPQL Los antecedentes de JPQL se pueden encontrar en la especificacin de EJB 2.0 con el lenguaje EJB-QL en el cual se introdujo una forma de navegar entre los Beans y sus relaciones, as como filtros y funciones agregadas. Los queries operan dentro de una unidad de persistencia y pertenecen a una de las siguientes clasificaciones: a) SELECT, son queries que recuperan una o ms entidades, filtrando los resultados si fuera necesario.
b) AGGREGATE, los queries de este tipo son variaciones de los queries del tipo SELECT, con la salvedad que agrupan resultados para producir informacin sumarizada (de ah la necesidad de usar la clusula GROUP BY ).
c) UPDATE, son queries que se emplean para actualizar un conjunto de entidades.
CIBERTEC
91
d) DELETE, son queries que se utilizan para remover un conjunto de entidades.
Al utilizar los queries se debe considerar que las entidades son referenciadas por su nombre. Si una entidad no tiene asignado un nombre de forma explcita, JPA asume el nombre de la clase como nombre por defecto: este nombre se conoce como abstract schema name de la entidad dentro del contexto del query. Tambin, es importante resaltar que para los queries es indiferente el uso de maysculas y minsculas salvo en dos casos: nombre de entidades y nombres de atributos de cada entidad. Dada una entidad como la siguiente ( entidad Employee ):
El query ms sencillo que se pueden ejecutar es:
Observe que la notacin es muy similar al SQL normal, pero con ligeras diferencias:
CIBERTEC
92
a) En JPQL, lo que sigue a la clusula FROM es el nombre de la entidad, es decir, no se coloca el nombre de la tabla (recordar que la Entidad mapea a una tabla). b) En JPQL, es obligatorio que las entidades sean calificadas con un alias: en el caso del ejemplo, el alias es e. Este alias se conoce como variable de identificacin. c) El alias indicar que el resultado ser uno o ms entidades del tipo correspondiente a la entidad. d) El tipo de resultado de un Query no puede ser una Coleccin. Debe ser un tipo simple o una Entidad. A partir del uso del alias para la entidad, se puede utilizar la notacin dot (el punto .) para referenciar campos persistentes de la entidad. Por ejemplo, si queremos seleccionar nicamente los nombres de los empleados sera as:
En este caso, como el campo nombre es un String, el resultado del query devolver uno o ms Strings. De la misma forma puede trabajarse para cualquier otro atributo, sea una lista, coleccin o campos simple. El seleccionar algunos campos de la entidad (al igual que en SQL) recibe el nombre de proyeccin. Se debe tener en cuenta su uso si es que se van a descartar (no usar) varios atributos de la entidad al momento de generar reportes (dada la sobrecarga que se genera en el framework JPA ). En el siguiente ejemplo, se puede seleccionar una entidad que no est en la clusula FROM:
Observe que departamento es una campo de la entidad Employee, pero a la vez es una Entidad (dada la relacin establecida @ManyToOne). Por tanto, el resultado de ese query ser una entidad Department obtenida a partir de la relacin.
FILTROS Al igual que en SQL, se puede filtrar los resultados a obtener utilizando la clusula WHERE y la notacin dot. JPQL incluye operadores como IN, LIKE y BETWEEN, funciones como SUBSTRING y LENGTH adems de soportar subqueries. Ejemplo:
CIBERTEC
93
En este ejemplo, el filtro lo constituye el atributo nombre de la entidad Department que est vinculada con la entidad Employee.
JOIN ENTRE ENTIDADES Al igual que en SQL, si se desea navegar entre las relaciones de las entidades y retornar elementos de la coleccin, se debe ejecutar un JOIN entre entidades. Se puede ejecutar el JOIN al ms puro estilo del tradicional SQL indicando los criterios de JOIN en la clusula WHERE. Sin embargo, JPQL proporciona la facilidad de especificar el JOIN dentro de la clusula FROM con la finalidad de expresar el JOIN en trminos de la relacin existente entre las entidades: JPA se encargar de armar la sentencia SQL equivalente. Un JOIN ocurre si se cumple cualquiera de las siguientes condiciones en el SELECT: 1) Dos o ms declaraciones de variables son listadas en la clusula FROM y aparecen en la clusula SELECT. 2) El operador JOIN es empleado para extender a una variable de identificacin usando expression path. 3) Un path expression en cualquier parte del query navega a travs de un campo de asociacin en la misma o en otra entidad. 4) Una o ms condiciones WHERE comparan atributos de variables de identificacin diferentes. Se debe tener en cuenta que ante la ausencia de condiciones de JOIN entre entitades, se generar un producto cartesiano entre la primera entidad y cada ocurrencia de la segunda entidad.
INNER JOIN Un inner join entre dos entidades se puede especificar de cualquiera de la maneras indicadas anteriormente. Sin embargo, la forma preferida es mediante el uso del operador JOIN en la clusula FROM. La sintaxis bsica es: [INNER] JOIN <path_expression> [AS] <identifier>
CIBERTEC
94
Ejemplo 1: se asume que phones contiene una relacin JPA entre Employee y Phone
Ejemplo 2: mltiples Joins ( los joins se interpretan de izquierda a derecha desde el FROM )
OUTER JOIN Un outter join entre dos entidades produce un mbito en el cual solo un lado de la relacin es requerido para completar el resultado. Por ejemplo, un outer join entre Empleado y Departamento mostrar todos los empleados y los departamentos a los que han sido asignados, pero con la salvedad que el Departamento ser retornado nicamente si existe dentro de la relacin ( a diferencia de un inner join ). Su sintaxis es la siguiente: LEFT [OUTER] JOIN <path_expression> [AS] <identifier>
Ejemplo 1:
FETCH JOIN Este tipo de Join sirve para ayudar a los programadores a optimizar los accesos a la base de datos. Permite que los queries especifiquen una o ms relaciones que deben ser navegadas y pre-cargadas por el mecanismo de recuperacin de datos de tal forma que no se ejecuten lazy load en tiempo de ejecucin. En otras palabras, reduce la cantidad de accesos a la base de datos. Ejemplo:
CIBERTEC
95
QUERIES AGREGADOS La sintaxis es muy similar a SQL: se requiere el uso del agrupamiento con GROUP BY Es opcional el uso del filtro mediante la clusula HAVING. JPA incluye cinco funciones agregadas: AVG : Promedio aritmtico. COUNT : Cantidad de repeticiones. MIN: Menor valor. MAX: Mayor valor. SUM: Suma de valores
Ejemplo:
En este ejemplo se obtienen todos los departamentos, la cantidad de empleados de cada departamento, el sueldo mximo y el sueldo promedio teniendo en consideracin slo aquellos departamentos que tengan ms de 5 empleados. QUERIES Existen dos formas para definir queries en JP-QL: La primera forma es definirlo dinmicamente en tiempo de ejecucin como una cadena de caracteres que se construye de acuerdo al flujo de la aplicacin. Esto implica compilar el query cada vez. La segunda forma es definir el query va anotacin o XML y referenciarlo por el nombre cada vez que se requiera (algo similar a IBATIS). A diferencia de la forma anterior, los queries nombrados son estticos, pero son mucho ms eficientes para ser ejecutados.
4.2 CONSULTAS DINMICAS Un query se puede definir de forma dinmica simplemente pasando una cadena de caracteres con la sentencia JPQL al mtodo createQuery() del EntityManager. Ahora bien, se puede indicar el resultado esperado o se puede omitir y de esta forma tendremos un query sin tipo definido ( unTyped query ).
CIBERTEC
96
Para aquellas aplicaciones que utilizan muchos queries, se debe considerar el costo de compilar la sentencia JPQL: 1) Se ejecuta un parse de la cadena JPQL en un rbol de sintaxis para verificar que est correctamente escrito. 2) Para cada entidad dentro de la expresin se obtiene la metadata. 3) Se genera la sentencia SQL equivalente. Se debe tener en consideracin (al igual que en JDBC) las implicancias de concatenar un query y luego pasarlo al EntityManager para evitar la inyeccin de cdigo SQL malicioso. Por ello es preferible usar parmetros. Tambien, para aquellos queries empleados con mayor frecuencia, es preferible usar los queries nombrados ( NamedQueries ). Un ejemplo con TypeQuery:
TypedQuery
La sentencia JP-QL
Clase que retorna el query
La clase Order.java tiene un mtodo toString()
CIBERTEC
97
Un ejemplo con Query : La sentencia JP-QL Query
La clase Order.java tiene un mtodo toString()
4.3 CONSULTAS NOMBRADAS Este tipo de query sirve para organizar y mejorar el desempeo de una aplicacin. Se define empleado la anotacin @NamedQuery, la cual se coloca dentro de la definicin de una Entidad: la anotacin define no solamente el nombre del query sino tambien la sentencia JPQL en s. Se recomienda escribir los queries de manera ordenada de tal forma que ayuden a la visibilidad y lectura de los mismos dentro de la definicin de la entidad. El nombre del query ( atributo name ) debe ser nico dentro de toda la unidad de persistencia. Si se hace caso omiso a esta restriccin, los resultados pueden ser imprevisibles en tiempo de ejecucin. Se puede definir mltiples queries nombrados empleando la anotacin @NamedQueries, la cual es un arreglo que acepta varias anotaciones @NamedQuery. Ejemplo: El mismo query del ejemplo anterior, pero ahora definido en la clase Order.java Nombre del Query Query JPQL
CIBERTEC
98
Se invoca as: Se especifica que es NamedQuery
Se especifica el nombre del Query
Si deseamos definir varios NamedQueries en la entidad, se tendra que hacer as:
Anotacin
Query JPQL #1
Query JPQL #2
Y se puede invocar as:
CIBERTEC
99
Se especifica el nombre del Query
4.4 USO DE PARMETROS Los parmetros enviados a un query permiten la reutilizacin de sentencias de forma tal que las consultas ejecutadas con diferentes parmetros en cada invocacin, retornen diferentes resultados. Es preferible enviar parmetros a las consultas en lugar de estar construyendo una nueva cadena de caracteres por cada invocacin, pues as se evita compilar repetidas veces los queries. PARMETROS NOMBRADOS Se utilizan cuando dentro de la sentencia JPQL, los parmetros van precedidos por el smbolo de : seguido del nombre del parmetro. Al momento de ejecutar el query, el programador debe especificar el nombre del parmetro (empleando el mtodo setParameter ) y el valor a ser cargado para reemplazarlo dentro de la sentencia JPQL. Los parmetros nombrados proporcionan claridad al cdigo de la sentencia JPQL ( cuando se utilizan nombres adecuados), por lo que son preferidos respecto a los parmetros ordinales. Ejemplo usando parmetros nombrados:
CIBERTEC
100
La sentencia JP-QL
Note el uso de named parameters
Colocando los valores
PARMETROS ORDINALES Se utilizan cuando dentro de la sentencia JPQL, los parmetros van precedidos por el smbolo de ? seguido del nmero del parmetro. Al momento de ejecutar el query, el programador debe especificar el nmero del parmetro y el valor a ser cargado para reemplazarlo dentro de la sentencia JPQL. Ejemplo con parmetros ordinales:
La sentencia JP-QL
Observe el uso de parmetros ordinales Se cargan los valores
4.5 EJECUCIN DE QUERIES JPA proporciona tres formas de ejecutar queries: a) Para queries que getSingleResult(). retornan un nico valor se aplica el mtodo
CIBERTEC
101
b) Para queries que retornan una lista de valores se aplica el mtodo getResultList(). c) Para queries que ejecutan sentencias de delete/update se aplica el mtodo executeUpdate().
Se debe tener presente que: a) Por defecto, los queries devuelven listas desordenadas. b) Cuando se aplica el mtodo getResultList(), el tipo de dato retornado es una Collection (si no hay resultados, se devuelve una Collection vaca ). Sin embargo, la variable Java que recibe los resultados debe ser de tipo List. Ejemplo:
c) Cuando se aplica el mtodo getSingleResult(), si no existen resultados se devuelve la excepcin NoResultException ( la aplicacin deber controlar la excepcin). La ocurrencia de sta excepcin no genera un rollback de la transaccin en curso. d) Cuando se aplica el mtodo getSingleResult(), si existen muchos resultados (en lugar de uno) se devuelve la excepcin NoUniqueResultException ( la aplicacin deber controlar la excepcin). La ocurrencia de sta excepcin no genera un rollback de la transaccin en curso. e) Cualquier query de tipo SELECT puede especificar adems el uso de modos de bloqueo para los registros seleccionados con el fin de no impactar en el base de datos los indicadores de rendimiento. Esto se ejecuta va el mtodo setLockMode().
CIBERTEC
102
4.6 SINTAXIS DE JPQL3
Trmino entityName variable state_field_exp
Descripcin Nombre de la Entidad. Por defecto es el nombre de la clase. Identificador que sigue las reglas de Java Trmino utilizado para apuntar hacia un campo de la entidad. Por ejemplo: Si Alumno est representado por la variable a, se puede apuntar a los campos como: a.codigo, a.nombre Trmino utilizado para apuntar hacia un campo de una entidad, pero que resuelve relaciones de tipo one-to-one o many-toone. Por ejemplo: Si Alumno est representado por la variable a, se puede apuntar a los campos como: a.cursos , a.cursos.notas
single_rel_exp
multi_rel_exp
Trmino utilizado para apuntar hacia un campo de una entidad, pero que resuelve relaciones de tipo one-to-many o many-tomany. Por ejemplo: Si Alumno est representado por la variable a, se puede apuntar a los campos como: a.telefonos
rel_field
Trmino compuesto de una variable y una de los campos relacionados sin navegar por relaciones intermedias. Por ejemplo: Si Alumno est representado por la variable a, se puede usar a.ciclo
constructor_method Constructor para una clase que no es Entidad. Input_param Variable que representa a un parmetro de entrada y debe ser asignado antes que el query sea ejecutado. Valor de un tipo particular ( por ejemplo un string como hola o un int como 99 ). Un string que representa un valor SQL vlido. Por ejemplo: %PEREZ escape_char Un carcter que representa una secuencia de escape.
literal
pattern_value
FUENTE: DZone RefCardz Getting started with JPA, Mike Keith. Sitio web: http://www.dzone.com
CIBERTEC
103
CIBERTEC
104
CIBERTEC
105
CIBERTEC
106
Resumen
Diferenciar las clases Query y TypedQuery. Recordar que el mtodo createQuery del EntityManager sirve para la creacin de consultas dinmicas. Recordar que el mtodo createNamedQuery del EntityManager sirve para la creacin de consultas nombradas, las cuales se definen como anotacin (utilizando @NamedQuery) dentro de la entidad respectiva. Las anotaciones @NamedQuery y @NamedQueries se utilizan para definir consultas nombradas El mtodo setParameter sirve para asignar un valor a un parmetro de una sentencia JPQL. Existen dos formas : por parmetro nombrado y por parmetro ordinal. Puede consultar el libro: Pro JPA 2 : Mastering the Java API Persistence Captulo 7. Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. http://www.objectdb.com/java/jpa/query/parameter En esta pgina, hallar mayor informacin.
CIBERTEC
107
JAVA SERVER FACES ( JSF )

Al trmino de la unidad, el alumno, construye una aplicacin web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework JSF (Java Server Faces) a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible.
TEMARIO
Tema 1: Arquitectura de JSF, Configuracin y estructura bsica 1.1. Introduccin a JSF 1.2. Arquitectura de JSF 1.3. Ciclo de vida de un request 1.4. Facelets 1.5 . ManagedBean 1.6. Lenguaje de Expresiones JSF 1.7. Backing Beans
Los alumnos configuran su entorno de desarrollo y pruebas con las libreras de JSF. Los alumnos desarrollan una aplicacin sencilla utilizando JSF.
CIBERTEC
108
TEMA 1: ARQUITECTURA DE JSF, CONFIGURACIN Y ESTRUCTURA BSICA.

1.1 INTRODUCCION A JSF Java Server Faces (JSF) es el estndar oficial en la capa web para la plataforma Java EE. JSF incluye un conjunto de componentes predefinidos para la interfaz grfica web ( UI ), un modelo de programacin basado en eventos y la habilidad para aadir componentes desarrollados por terceros. El objetivo de la tecnologa Java Server Faces ( JSF ) es construir aplicaciones web de forma similar a como se construyen aplicaciones standalone con Java Swing, AWT (Abstract Window Toolkit), SWT (Standard Widget Toolkit) o cualquier otra API similar. JSF fue creado mediante el trabajo de la organizacin JCP ( Java Community Process ) mediante la especificacin JSR 127 iniciada a mediados del ao 2001 y finalizada en Marzo del 2004. Su principal objetivo es facilitar el desarrollo de interfaces grficas para las aplicaciones web por medio de los siguientes caminos: Proporciona un desarrollo basado en componentes, independientes del cliente. De esta manera se incrementa la productividad del desarrollador. Simplifica el acceso y administracin de los datos capturados o enviados a la interfaz de usuario. Maneja de forma automtica el estado de la interfaz de usuario entre mltiples peticiones HTTP. Proporciona un framework amigable mediante el uso de patrones de arquitectura para las aplicaciones web.
En resumen, toma los mejores elementos de los frameworks que le precedieron (CGI, Servlet, JSP, Struts, Spring MVC ) y los combina en un conjunto de APIs estndares para el desarrollo de interfaces de usuario. La versin actual es JSF 2.0 y est soportada por las siguientes especificaciones: JSR 127 : Java Server Faces ( http://www.jcp.org/en/jsr/detail?id=127 ) JSR 252: Java Server Faces 1.2 ( http://www.jcp.org/en/jsr/detail?id=252 ) JSR 276: Design-Time Metadata for (http://www.jcp.org/en/jsr/detail?id=276 ) JavaServer Faces Components
JSR 314: Java Server Faces 2.0 (http://www.jcp.org/en/jsr/detail?id=314 )
Al ser JSF una especificacin, se pueden encontrar implementaciones de diferentes fabricantes, lo cual permite no vincularse con ningn proveedor en particular y tener la total libertad de seleccionar aquel que ms se acomode a nuestras necesidades. Algunas implementaciones de JSF 2.0 son:
CIBERTEC
109
Proyecto Mojarra ( La implementacin de referencia de SUN Microsystems ahora propiedad de Oracle Corp.). Se puede consultar en el siguiente enlace: https://javaserverfaces.dev.java.net/ Oracle ADF Faces, que extiende la funcionalidad de JSF proporcionando muchas funcionalidades Ajax. MyFaces ( Fundacin Apache http://myfaces.apache.org/ ). Rich Faces, alojado por Jboss (Grupo RedHat) en el siguiente enlace: http://jboss.org/richfaces . ICE Faces, que contiene diversos componentes para interfaces de usuario ms enriquecidas. Se puede obtener informacin en el enlace: http://www.icefaces.org/main/home/ . jQuery4jsf que contiene componentes basados en el Framework JavaScript jQuery. Es un proyecto alojado por Google Code en el siguiente enlace: http://code.google.com/p/jquery4jsf/
1.2 ARQUITECTURA DE JSF
Los objetivos de diseo de JSF y la manera en que los cumple se aprecian en el cuadro siguiente: Objetivo de Diseo Objetivo #1: Crear un framework estndar de componentes UI que pueda ser potenciado por herramientas de desarrollo y que a su vez permita crear UI de alta calidad y manejar la incorporacin de dichas UIs a la aplicacin. Objetivo #2: Definir un conjunto ligero de clases Java para los componentes UI, el estado de los componentes y el manejo de eventos. Objetivo #3: Proporcionar un conjunto comn de Forma de Implementacin JSF proporciona una API basada en componentes que se pueden usar para ensamblar aplicaciones web. Los componentes UI estndar proporcionados por la especificacin, estn acompaados de tag libraries de tipo core y html (con funcionamiento muy similar a JSTL)
CIBERTEC
110
componentes UI incluyendo los elementos estndares para formularios HTML. Dichos componentes deben poder servir para definir nuevos componentes. Objetivo #4: Proporcionar un modelo de JavaBeans para controlar los eventos en el lado cliente y conectarlos a la aplicacin.
JSF proporciona un mecanismo de fcil empleo mediante el cual los componentes UI en el lado web estn dbilmente acoplados (mediante un Lenguaje de expresiones similar a JSTL) a los POJOs del servidor ( conocidos como Managed beans ) Los managed Beans se declaran en el archivo faces-config,xml o se usan anotaciones.
El control de la conversacin se realiza en el JSF request process Lifecycle. Objetivo #5: El JSF request process lifecycle tambin Definir APIs para validacin de datos de permite manejar las validaciones y conversiones entrada. dependiendo de los eventos que ocurren en la aplicacin. JSF permite construir validaciones personalizadas. Objetivo #6: JSF proporciona el manejo de resource Especificar un modelo para el manejo de bundles as como de localizacin ( L10N ). Los i18N en los componentes UI. componentes UI automticamente reconocen estas caractersticas una vez que el bundle ha sido configurado. Objetivo #7: JSF proporciona APIs bastante flexibles Proporcionar una generacin automtica basadas en tecnologas de rendering que del formato apropiado de salida hacia un pueden ser enchufadas bajo demanda. Por cliente determinado. ejemplo, si el cliente es un iPhone el render de la pgina ser HTML especfico para dicho Objetivo #8: equipo. Soportar accesibilidad
JSF confa plenamente en las tecnologas existentes de Java EE. Eso significa que una aplicacin JSF es bsicamente una aplicacin desarrollada bajo los estndares Java EE con algunas configuraciones especficas: Configuracin #1: Dentro del deployment descriptor ( archivo web.xml ) de la aplicacin, se debe registrar el servlet controlador ( llamado Faces Controller ). Tener en cuenta que en algunos contenedores web como GlassFish v3 no se requiere el archivo web.xml.
CIBERTEC
111
En caso que el archivo web.xml no exista o no se encuentre, el Faces Controller mapea los urls siguientes de forma automtica: /faces/* *.jsf *.faces
Tambin se puede agregar los siguientes mappings en el web.xml:
Configuracin #2: Opcionalmente se puede tener un archivo de configuracin de JSF llamado faces.config.xml el cual est ubicado al mismo nivel que el web.xml
El archivo contiene la configuracin de todos los elementos de una aplicacin JSF, aunque tambin pueden emplearse anotaciones en el cdigo java para evitar el uso de ste archivo. Un ejemplo del contenido del archivo faces-config.xml es:
CIBERTEC
112
Estas reglas se conocen como JSF Navigation Model
Configuracin #3 : Si se est ejecutando la aplicacin en un contenedor web que no soporta a JSF, las libreras del framework deben colocarse en el folder lib de la aplicacin:
La construccin de pginas se realiza con Facelets XHTML empleando para ello tag libraries. Se puede declarar las libreras usando XML namespaces o usando la forma tradicional:
CIBERTEC
113
En resumen, una aplicacin JSF es como cualquier aplicacin web que incluye los siguientes elementos: Las paginas web. Las libreras de etiquetas ( o tags ) para insertar componentes UI a las pginas. Un conjunto de backed beans, que son componentes que definen las propiedades y funcionalidad de los componentes de UI. Archivos de configuracin para el modelo navigacional ( aunque es opcional ). El indispensable archivo descriptor web.xml Archivos desarrollados por los programadores: convertidores, validadores, listeners. Opcionalmente algunas etiquetas personalizadas para objetos UI personalizados.
1.3 CICLO DE VIDA DE UN REQUEST El ciclo de vida de una peticin JSF es la secuencia de eventos que suceden cuando se hacen peticiones HTTP con una aplicacin JSF ( la interaccin entre el navegador web y la aplicacin ). La primera vez que se ejecuta la peticin, JSF crea un rbol de componentes UI en memoria. Para las siguientes peticiones el rbol es rpidamente construido de nuevo: si se capturan valores en un formulario, stos son procesados y validados. Si la validacin es correcta, los valores capturados son cargados al modelo. Luego se procesan los eventos y se reportan los errores que pudieran ocurrir. Si todos los eventos han sido procesados y el modelo ha sido actualizado correctamente se enva una respuesta final (render) al cliente. El manejo del ciclo de vida de manera automtica lleva un control de los cambios en los estados de tal forma que el cliente siempre refleje los cambios en el lado servidor. El ciclo completo se muestra en el grfico:
CIBERTEC
114
Una explicacin detallada del ciclo: FASE 1: Restore View El concepto de Faces View es la representacin en el lado servidor4 ( a manera de espejo ) de la interfaz de usuario que se muestra en el navegador. En esta fase se restaura una vista existente de alguna transaccin anterior o se genera una nueva en funcin a la peticin HTTP entrante. Si la peticin es nueva, se genera una vista que se almacena en un objeto conocido como Faces Context , el cual sirve como almacenamiento para los datos de la peticin http durante el manejo del ciclo de vida. La vista generada sigue una estructura de rbol como la siguiente5:
FASE 2: Apply Request Values En esta fase se ejecuta todo el trabajo de procesar los pares de datos (conocidos como value-pair parameters) que llegan en el request desde la pgina mostrada en el lado cliente: el parmetro y su valor. De esta manera, cada elemento del rbol que representa a la Faces View se carga con el valor respectivo como se muestra en el grfico6:
A diferencia de una estructura de rbol DOM que se forma en el navegador, en el caso de la Faces View se genera en el lado del servidor.
5
Grfico tomado de : Java Server Faces 2.0: The Complete Reference , pg 40 Grfico tomado de : Java Server Faces 2.0: The Complete Reference , pg 41
CIBERTEC
115
Se debe especificar que existen dos tipos de componentes UI: Aquellos que pueden aceptar valores: campos de texto, cajas de chequeo, etc. Aquellos que permiten ejecutar acciones: botones y enlaces.
Es bueno saber que se puede alterar el curso normal de las fases para casos especiales. Para ello se debe configurar el atributo immediate en un componente UI. Tambien es bueno especificar que existen 3 tipos de interfaces usadas: ValueHolder : implementada por todos los componentes UI que tienen el atributo value EditableValueHolder: implementada por todos los componentes UI de un formulario, que poseen valores editables. ActionSource : implementada por los componentes que generan acciones.
FASE 3: Process Validations En esta fase se ejecuta la conversin y validacin de los datos recibidos. JSF invoca al mtodo processValidators() en la instancia raz de UIViewRoot el cual se propaga recursivamente hacia los componentes UI del rbol. Cuando cada mtodo processValidators() de cada componente es invocado, se ejecutan las conversiones y/o validaciones especificadas.
CIBERTEC
116
Si ocurre algn error de conversin o validacin, la propiedad valid se marca en false y se encola un objeto FacesMessage en el FacesContext. Estos objetos sern mostrados posteriormente en la vista del lado cliente. FASE 4: Update Model Values En esta fase, los datos se promueven hacia un objeto Java conocido como Managed Bean. El mecanismo es similar a las fases anteriores: en la instancia UIViewRoot se ejecuta el mtodo processUpdate() el cual se propaga en cascada. Slo los componentes definidos como tipo UIInput pueden enviar datos a un objeto Managed Bean. Al final la fase, todos los atributos del objeto managed bean tienen cargados los valores de la Faces View como se muestra en el grfico7:
FASE 5: Invoke Application Es en esta fase en la que cualquier cdigo personalizado se puede ejecutar. FASE 6 Render Response En esta fase se ejecutan mtodos encodeXXX() para enviar el componente al cliente. Los encode los que hacen es seleccionar l mejor tipo de lenguaje de marcas apropiado para el cliente: HTML, WML, XML, etc.
Grfico tomado de : Java Server Faces 2.0: The Complete Reference , pg 43
CIBERTEC
117
Adicionalmente se graba el estado actual de la Faces View para que est disponible en los subsiguientes requests.
Java Server Faces permite adems que se pueda codificar phase listeners para controlar la ejecucin de cdigo en algn punto exacto del ciclo de vida del request. Para ello se debe: implementar la interface PhaseListerner registrar la clase en el archivo faces-config.xml o usar anotaciones
1.4 FACELETS La tecnologa denominada Facelets View Declaration Language (VDL) fue desarrollada como una extensin de JSF por Jacob Hookom e incorporada a la especificacin JSF 2.0. El objetivo fue reemplazar el uso de JSP (aunque se mantiene el reconocimiento de los JSP por motivos de compatibilidad). Los Facelets permiten a los desarrolladores declarar componentes UI en diferentes tecnologas de presentacin utilizando para ello plantillas (templates) HTML. La meta de diseo principal fue permitir la composicin de una vista a partir de diferentes pginas fsicas separadas8. Algunos conceptos importantes en esta tecnologa: a) Pgina (page) : Se define as a la totalidad de la pgina web que es mostrada al usuario. Se asocia con una viewId en el modelo de navegacin. b) Fragmento de pgina ( page fragment ): se generan y utlizan como si fueran pginas, siendo la principal diferencia que los fragmentos no son pginas web completas sino que se emplean para armar pginas completas.
8
Patrn de diseo Composite View
CIBERTEC
118
c) Pgina de Plantilla ( page template ): son formatos reutilizables que se emplean para construir pginas y/o fragmentos. Si existen porciones de pgina que son comunes en muchas pginas web, se pueden crear plantillas para dichas porciones. d) Facet: son reas dentro de la pantilla en donde el contenido puede ser agregado por los desarrolladores cuando generan las pginas. Los facets pueden tener un contenido por defecto. En la tecnologa JSP, los templates era codificados mediante el uso de: jsp:incluye <%@include %>
En la tecnologa JSTL se utilizaba <c:import /> Las pginas en Facelets se generan usando XHTML. La idea de usar XHTML es hacer portables a las pginas entre diversos ambientes de desarrollo. Adems, Facelets requiere el uso de XML namespaces para soportar las siguientes libreras de tags: JSF HTML Tag Library. JSF Core Tag Library. JSTL Core Tag Library. JSTL Functions Tag Library. JSF Facelets Tag Library. El encabezado de la pgina debe ser similar a esto (dependiendo de las libreras a utilizar):
Las pginas en Facelets deben tener extensin .xhtml En el archivo web.xml de la aplicacin debe configurarse los siguientes context param:
CIBERTEC
119
El primer parmetro define que la extensin .xhtml es el sufijo por defecto de todas las pginas que manejan contenido JSF. El segundo parmetro indica que la implementacin de JSF ignore los comentarios XML en las pginas Facelets. Una comparativa9 entre JSP y Facelets:
Una gran caracterstica de los Facelets ( no disponible en JSP ) es el poder generar templates. Un template es una pgina XHTML que emplea algunos tags de Facelets para definir varias divisiones lgicas de la vista como por ejemplo: cabecera, pie de pgina y contenido. La idea es tener partes reusables de cdigo sin tener que repetir el mismo cdigo en diferentes pginas.
Tomada del Libro: Java Server Faces 2.0: The Complete Reference , pg 58
CIBERTEC
120
Existen dos perspectivas para desarrollar Templates10: Template File: es el archivo conteniendo la plantilla o estructura de composicin (formato) a generar. El contenido de este archivo est compuesto por: a. El contenido que debe ser mostrado a todos los clientes se escribe directamente en el archivo. b. El contenido que se puede reemplazar en cada archivo cliente se marca con el tag <ui:insert>. c. El template nunca debe ser accedido directamente por los clientes. Template Cliente file: es el archivo que corresponde con una viewId. Emplea una o ms pginas para generar el contenido basado en el Template File. Este archivo contiene: a. La especificacin del template file mediante el tag <ui:composition> b. La especificacin del contenido a reemplazar con el tag <ui:define> (que se asocia al tag <ui:insert> del template file ).
Esquemticamente se puede ver as:
10
Muy similar a Apache Tiles
CIBERTEC
121
La tecnologa de Facelets proporciona tags en la librera denominada ui cuyo namespace es http://java.sun.com/jsf/facelets : Tag ui:composition Descripcin Se usa en archivos que funcionan como Template Client. Este tag le dice a JSF que los tags internos deben incorporarse a la jerarqua de UIComponent Especifica el template a emplear. El texto que se encuentre fuera de los tags <ui:composition> no se toma en cuenta para el render de la pgina. Se diferencia del anterior en que el contenido dentro del tag es incluido en la pgina antes que recortado (como en el caso del ui:composition) Es muy til cuando se tiene una serie de elementos de una pgina que requieren la misma apariencia. Se usa en archivos que funcionan como Template Client. Define una regin que ser insertada dentro de la composicin (ui:composition). Se usa en archivos que funcionan como
ui:decorate
ui:define
ui:insert
CIBERTEC
122
ui:include
ui:param
ui:component
ui:fragment
ui:remove
ui:debug
Templates nicamente para indicar en que parte del archivo se insertar el correspondiente <ui:define> del template cliente. Al combinarse con <ui:param> permite la inclusin personalizada de pginas. Puede estar presente tanto en el Template como en el Template Client. Se usa exclusivamente dentro del <ui:include> para definir parejas de valores (nombre y valor) disponibles va expresiones EL. TAGS QUE NO SON PARTE DE LOS TEMPLATES Sirve para asociar tags del cdigo a un determinado UIComponent dentro del rbol. Similar a ui:component con la diferencia que enmascara una serie de componentes dentro de un componente padre antes de incluirlo en el rbol de la vista. Se emplea para comentar un fragmento de los tags y evitar que se muestren en la vista. Permite que al presionar una tecla se active una ventana mostrando el rbol de componentes, las variables activas y cierta informacin para depurar la aplicacin. Se debe configurar context-param en el web.xml con el valor: javax.faces.FACELETS_DEVELOPMENT Sino se especifica hockey, el valor por defecto es CTRL-SHIFT-D
Ejemplo de Template: Observe las primeras lneas de cdigo y anote las declaraciones en el tag <html> : se declaran los namespaces de las libreras. Observe los bloques con el tag <ui:insert>. Lo que est dentro del bloque es el valor por defecto de esa zona ( si es que el viewID no reemplazara nada ). Observe la lnea 9 para ver el uso de resources folders. En este caso, la aplicacin busca un folder resources y dentro de este, busca el nombre de la library que est como parmetro ( css ). Los tags <ui:include> permiten incoporar contenido que se encuentra en otros archivos, dentro del template o de la viewId.
CIBERTEC
123
Ejemplo de viewID o pgina cliente: Observe las declaraciones del tag <html> en la primeras lneas. En la lnea 10 se declara el <ui:composition> para indicar cual es el archivo de layout con el que trabaja sta pgina. Los bloques <ui:define> sirven para reemplazar el contenido de cada bloque dentro de la zona de la plantilla identificada con el mismo nombre. Tenga en cuenta que el contenido que se encuentre fuera de los tags <ui:composition> no aparecer en los clientes.
CIBERTEC
124
Ejemplo de tag <ui:decorate>:
En este caso se mostrar tanto el texto anterior como posterior al tag.
CIBERTEC
125
1.5 MANAGED BEANS Al igual que el Framework Spring que proporciona la nocin de Inversin de Control (IoC), JSF tambien proporciona una robusta habilidad para ello con las facilidades de los Managed Beans. Una Managed Bean es una clase Java que representa informacin de un formulario web. Para ello hace uso de los POJOs ( Plain Old Java Objects ), que son objetos que almacenan datos de la aplicacin pero que no implementan o extienden ninguna interfaz o clase especfica de algn Framework. Un POJO declarado dentro de una aplicacin JSF se convierte en un Managed Bean al cual nunca se le generar utilizando el mtodo new de una clase Java. En lugar de ello, el contenedor JSF inicializar el objeto nicamente cuando la aplicacin lo requiera ( Lazy initialized ). Cualquier clase Java que siga las reglas de los Java Beans pueder ser registrado como una Managed Bean. Debe tenerse en cuenta que hay dos maneras de configurar los managed bean: Usando anotaciones dentro del programa Java. Es la forma ms recomendada pues permite un cdigo ms cohesionado y fcil de mantener. Se emplea la anotacin @ManagedBean antes de la definicin de la clase (desde JSF 2.0). Usando XML dentro del archivo faces-config.xml. Se emplea el tag <managed-bean> para efectuar la declaracin.
Un managed Bean tpicamente tiene 3 partes : a) Las propiedades del Bean : generalmente un getter y un setter por cada atributo. Los mtodos setter son invocados automticamente por el JSF cuando el formulario web es enviado. b) Mtodos para controlar acciones: Generalmente es slo un mtodo, pero podran ser varios si es que el formulario posee mltiples botones de envo. c) Un lugar para los datos resultantes: No es invocado automticamente por JSF. Debe ser llenado por el mtodo controlador en base a los resultados de la lgica de negocio. Un ejemplo de una aplicacin sencilla JSF: Se presenta un formulario donde se debe ingresar un nombre y presionar el botn de saludar. La aplicacin responde con una pgina de saludo.
CIBERTEC
126
El Managed Bean es bastante sencillo :
CIBERTEC
127
Y la pgina de respuesta:
Como se ve en el ejemplo, el Managed Bean est marcado para funcionar en el mbito @SessionScoped. Sin embargo, los mbitos pueden ser: mbito Puede referenciar a otros managed Beans del mbito Los Managed Beans con ste none mbito no se generan ni almacenan en ningn mbito. Ellos son generados bajo demanda por otros Managed Beans. Su tiempo de vida depende del Managed Bean que lo invoc. Pueden ser generados y estn none, request, disponibles durante una view, session, peticin HTTP simple. application Esto significa que el Bean sobrevive a la navegacin hacia Descripcin
none @NoneScoped (slo JSF 2.0)
request @RequestScoped
CIBERTEC
128
view @ViewScoped (slo JSF 2.0)
otra pgina. Permanecen disponibles none, view, durante el tiempo que el usuario session, permanezca en la misma vista. application Al salir de dicha vista, los Managed Beans son eliminados. Se almacenan en la sesin HTTP. Esto significa que los valores de sus atributos son almacenados a lo largo de mltiples peticiones HTTP para un usuario. Retienen sus valores a lo largo de la vida de una aplicacin, por lo que estn disponibles para TODOS los usuarios. El bean se almacena en un Mapa y el desarrollador tiene el control del ciclo de vida del mismo.
session @SessionScoped
none, session, application
application @ApplicationScoped
none, application
Custom @CustomScoped(value="#{so meMap}")
1.6 LENGUAJE DE EXPRESIONES JSF El lenguaje de expresiones utilizado en JSF 1.0 y 1.1 era una extensin del JSP Standard Tag Library (JSTL). La principal extensin que se introdujo en EL con JSF y que no est presente en versiones anteriores es el concepto de expresiones diferidas ( deferred expresiones ). En JSP, todas las expresiones que aparecen entre ${ } se evalan inmediatamente tan pronto como la pgina en renderizada. JSF introduce el procesamiento del ciclo de vida del request que controla lo que sucede cuando se ejecuta un submit. Para ello, se introduce el concepto de expresin diferida para permitir que las expresiones sean utilizables tanto durante el rendering de la pgina como durante el submit. Este concepto permite que una expresin entre smbolos #{ } como por ejemplo #{usuario.nombre} sirva tanto para mostrar un valor al usuario como tambin para recibir el valor ingresado por el usuario.
El objetivo de tener un Lenguaje Unificado de Expresiones ( EL ) es proporcionar una manera fcil de acceder a los objetos desde cualquier punto de la aplicacin. En general EL: Evita la necesidad de referir al objeto padre ( request, sesin o application). Evita usar directamente los mtodos get/set del objeto. Permite navegar de forma arbitraria en la jerarqua de objetos JavaBeans (usando la notacin .dot ).
Por ejemplo:
CIBERTEC
129
Esta expresin es una forma abreviada de invocar al mtodo getFirstName() de una Managed Bean llamado userBean: La primera parte ( en este caso userBean) es la BASE que indica el mbito donde buscar. La segunda parte ( en este caso firstName) es la propiedad, la cual puede navegarse usando la notaicn .dot.
Una facilidad que brinda E.L. es la invocacin directa a mtodos pblicos y no estticos de los managed beans. Por ejemplo:
NOTA: Para que E.L. sea lo ms simple posible, no est permitido el envo de parmetros a los mtodos. JSF busca los objetos en un orden jerrquico comenzando por los objetos implcitos para luego buscar en los managed beans de la aplicacin. El siguiente cuadro resume los objetos implcitos que pueden constituir la BASE:
CIBERTEC
130
NOTA: 1) Las propiedades de los objetos que son de tipo Map se acceden usando:
#{ MapObject [key] }
2) El objeto Flash es un tipo de almacenamiento temporal que permite que los datos estn presentes en el siguiente request. 1.6.1. OPERADORES E.L. Adems de los corchetes ( para Map) y del punto ( . ) existen otros operadores como se muestra en la tabla siguiente:
CIBERTEC
131
1.7 BACKING BEANS Para implementar los backing beans en JSF, se debe crear una clase Java por cada pgina JSF y registrar dicha clase como una managed bean. Lo usual es que la clase Java se llame igual que la pgina. Se recomienda que los backing beans se declaren en el mbito del request. En general, los backing beans se encargarn de armar toda la tubera necesaria entre la pgina y el modelo, porque: Contienen las propiedades correspondientes a los campos de entrada del formulario. Contienen action methods y action listener que corresponden a los componentes UI. Contienen declaraciones de instancias de componentes UI que se vinculan a los componentes UI utilizados en la pgina.
CIBERTEC
132
Resumen
JSF es una especificacin, por tanto tiene varias implementaciones de diversos fabricantes. Bsicamente tiene 4 libreras: core, html, user interface y composite que pueden ser complementadas con libreras de otros fabricantes. El lenguaje de expresiones requiere la sintaxis: #{ } y permite la referencia a propiedades de managed beans como tambin a mtodos. JSF tiene dos formas de navegacin: la implcita y la explcita ( que requiere el uso del archivo faces-config.xml ) JSF permite el empleo de plantillas mediante el uso de los tags d ela librera ui. Puede profundizar los conceptos tratados en el libro: The Complete Reference : Java Server Faces 2.0 Captulos 1, 2, 3, 4 y 5 Si desea investigar ms acerca de estos temas, puede consultar las siguientes pginas. http://www.mkyong.com/jsf2/jsf-2-templating-with-facelets-example/ Aqu hallar un ejemplo del uso de Facelets. http://www.mkyong.com/jsf2/jsf-2-0-hello-world-example/ En esta pgina, hallar un ejemplo bsico de JSF.
CIBERTEC
133

TEMARIO
Tema 2: Componentes de Interfaz de usuario 2.1. 2.2. 2.3. 2.4. 2.5. 2.6 . Introduccin Arquitectura de Componentes UI Librera Core. Librera HTML. Librera User Interface Librera de Componentes Compuestos.
Los alumnos desarrollan una aplicacin sencilla utilizando JSF y aplicando los tags que proporcionan las libreras.
CIBERTEC
134
TEMA 2: COMPONENTES DE INTERFAZ DE USUARIO.

2.1 INTRODUCCIN Los componentes UI Java Server Faces son elementos configurables y reutilizables que componen la interfaz de usuario de las aplicaciones Java Server Faces. Un componente se define como una pieza de software con reglas de uso bien definidas que permitan que pueda ser utilizado por otros componentes. Un componente de interfaz de usuario ( UI Component ) es un tipo especfico de componente que muestra contenido que puede ser modificado por el usuario a lo largo del tiempo. Este contenido puede ir desde un simple campo de ingreso de datos o botones, hasta elementos ms complejos como rboles o datagrids. La tecnologa Java Server Faces proporciona un conjunto de clases de componentes UI, que especifican toda la funcionalidad del componente, cmo mantener su estado, mantener una referencia a objetos del modelo, y dirigir el manejo de eventos y su representacin para un conjunto de componentes estndar. Estos componentes son completamente extensibles, lo que significa que podemos extenderlas para crear nuestros propios componentes personalizados. Es ms, la tecnologa JSF es tan flexible que proporciona una arquitectura de componentes que incluye: Un conjunto de clases UIComponent para especificar el estado y comportamiento de componentes UI. Un modelo de representacin (rendering) que define cmo representar los componentes de diferentes formas. Un modelo de conversin que define cmo conectar conversores de datos a un componente. Un modelo de validacin que define cmo registrar validadores con un componente. Un modelo de eventos (events) y oyentes ( listeners) que define cmo manejar los eventos de los componentes.
Todas las clases de componentes UI de Java Server Faces descienden de la clase UIComponentBase, que define el estado y el comportamiento por defecto de un UIComponent. Las clases auxiliares como Renderer, tag Handlers, Validador, Converter, etc tcnicamente no son Componentes UI porque no colaboran en la representacin visual del componente. Los Componentes UI adems tienen un conjunto de archivos como imgenes, hojas de estilo y JavaScripts que generalmente son responsables de la apariencia y comportamiento de componente dentro de una pgina web. La especificacin JSF se refiere a dichos archivos como recursos.
CIBERTEC
135
2.2 ARQUITECTURA DE COMPONENTES UI Los componentes UI se pueden clasificar en dos tipos: Aquellos que inician una accin como por ejemplo los botones. Aquellos que proporcionan datos como los campos de ingreso. En JSF, los componentes se pueden ubicar en una de las dos clasificaciones mencionadas en base a las interfaces que implementan segn la especificacin JSF (para el primer caso es la interface ActionSource2 y para el segundo caso es la interface ValueHolder o la interface EditableValueHolder). La razn para el uso de interfaces es utilizar la ms alta abstraccin posible con el fin de encapsular las capacidades de todos los componentes UI. De esta manera es mucho ms fcil entender todos los componentes JSF simplemente comprendiendo las interfaces que se implementan. Se debe indicar que los componentes, adems de las interfaces mencionadas, pueden implementar otras interfaces para definir un comportamiento particular. El siguiente cuadro resume esta clasificacin:
CIBERTEC
136
Interfaz
Caractersticas de un componente que implementa la interfaz Tiene un valor que puede ser editado por el usuario y enviado al servidor. La edicin del valor puede deshabilitarse temporalmente
EditableValueHolder
ActionSource2
PartialStateHolder
ValueHolder
NamingContainer
Ocasiona la ejecucin de un ActionEvent cuando el usuario presiona click sobre el componente. Tiene un estado que necesita Cada componente mantenerse entre peticiones UIComponent y cada HTTP. componente de ayuda (Helper class ) Tiene un valor que no puede ser UIOutput editado por el usuario. Es diferente al componente cuya capacidad de edicin puede ser deshabilitada. Proporciona un mbito de UIForm nombres para sus componentes UINamingContainer hijos UIData
Algunos componentes ( y las subclases ) que implementan la interfaz UIInput UISelectBoolen UISelectMany UISelectOne UIViewParameter UICommand
ClientBehaviorHolder Soporta el comportamiento del Todos los componentes HTML cliente como por ejemplo Ajax estndares.
La jerarqua de clases de los componentes11 dentro del paquete javax.faces.component es la siguiente (donde la flecha continua significa herencia y la discontinua significa implementacin):
11
Fuente: Libro Java Server Faces 2.0: The Complete Reference, pg 140.
CIBERTEC
137
Si bien sta jerarqua encapsula al componente, no describe la forma en que dicho componente ser mostrado al usuario. Un ejemplo de algunos componentes UI: UICommand: Representa un control que dispara actions cuando se activa. UIForm: Encapsula un grupo de controles que envan datos de la aplicacin. Este componente es similar a la etiqueta HTML <form> . UIGraphic: Muestra una imagen. UIInput: Toma datos de entrada del usuario. Esta clase es una subclase de UIOutput. UIOutput: Muestra la salida de datos en un pgina. UIPanel: Muestra una tabla.
CIBERTEC
138
UISelectItem: Representa un slo tem de un conjunto de tems. UISelectItems: Representa un conjunto completo de tems. UISelectBoolean: Permite a un usuario seleccionar un valor booleano en un control.Esta clase es una subclase de UIInput. UISelectMany: Permite al usuario seleccionar varios tems de un grupo de tems. Esta clase es una subclase de UIInput. UISelectOne: Permite al usuario seleccionar un tem de un grupo de tems. Esta clase es una subclase de UIInput.
Adems, JSF proporciona un conjunto de componentes UI para HTML que facilitan el desarrollo de aplicaciones web especficamente para clientes HTML ( navegadores ). Dicho conjunto de componentes reside en el paquete javax.faces.component.html y derivan de la misma jerarqua de clases mostrada, con la caracterstica especfica de trabajar para clientes HTML. Normalmente el desarrollador no trabajar con los componentes directamente sino que aprovechar las caractersticas proporcionadas por el Renderer de JSF: un Renderer es una clase responsable de tomar una instancia del UIComponent y generar la salida a ser mostrada segn las caractersticas especficas del cliente. Como se mencion en el tema del ciclo de vida de un request JSF, el rbol de componentes UI (que se conoce como Vista) es manejado por el ViewHandler. Sin embargo, el StateManager se encarga de preservar el rbol de componentes entre los subsiguientes requests. Para ello, se guarda el estado completo de los componentes utilizando un mecanismo especificado en el web.xml de la aplicacin:
Los parmetros a colocarse pueden ser : server: significa que el estado de la aplicacin debe almacenarse en el servidor entre cada request. Este es el comportamiento por defecto, por lo que no es necesario colocarlo en el web.xml. client: significa que el estado de la aplicacin se almacena en el cliente. Se almacena como una marca dentro de la pgina de forma tal que aparezca escondida y sea enviada como un campo oculto ( tipo hidden ).
La librera de componentes estndares est compuesta por cuatro libreras: La librera CORE: se asocia al namespace f: y proporciona utilidades para validacin, conversin, internacionalizacin, etc. La librera core no es especfica para clientes HTML dado que ninguno de sus componentes tiene una representacin visual en el lado cliente. La librera HTML: se asocia al namespace h: y est diseada especficamente para clientes HTML dado que proporciona un conjunto de objetos comunes a muchas aplicaciones web: botones, campos de texto, etc. La librera de tags para Plantillas FACELET: asociada al namespace ui: permite agregar funcionalidades de plantillas y formatos. Fue introducida en JSF 2.0.
CIBERTEC
139
La librera de tags para Componentes Compuestos: introducida tambin con JSF 2.0, se registra bajo el namespace cc: y agrega la habilidad para definir un contrato de uso con componentes compuestos.
2.3 LIBRERA CORE El namespace con el que se declara es http://java.sun.com/jsf/core y se le asigna el prefijo f. Se listan las principales funcionalidades de cada tag. Para el detalle de los atributos soportados, por favor consultar la documentacin de JSF. Tag <f:actionListener> Permite al desarrollador registrar de forma declarativa una instancia de ActionListener sobre un Componente UI. Un ActionListener es un manejador de evento que responde a eventos que suceden en la pgina JSF.
Tag <f:ajax> Permite al desarrollador agregar de forma declarativa, comportamiento Ajax al componente asociado. Tag <f:attribute> Agrega un atributo con un nombre especfico y un valor string a un componente dentro del tag si es que dicho componente no contiene un atributo con dicho nombre. Los valores se almacenan en un Map que es parte del componente de tal forma que los valores persisten cuando se administra el estado de dicho componente.
Tag <f:convertDateTime> Se utiliza para convertir valores String a valores java.util.Date.
CIBERTEC
140
Tag <f:convertNumber> Se utiliza para convertir valores String a valores java.lang.Number.
Este tag maneja una serie de patrones para formateo de los valores. Tag <f:converter> Este tag crea una instancia de la clase Java registrada con el ID especificado, la cual debe implementar a la interfaz javax.faces.convert.Converter. Luego, asocia esta instancia con el componente UI ms cercano.
Tag <f:event> Permite que el desarrollador registre de manera ComponentSystemEventListener en un componente UI.
declarativa
un
Soporta dos atributos: listener: cuyo valor debe ser un Method Expression que se refiere a un mtodo con la misma firma que el mtodo processEvent de la interfaz ComponentSystemEventListener. type : especifica el nombre del evento. preRenderComponent preRenderView postAddToView preValidate postValidate Ejemplo:
Tag <f:facet> Representa un componente anidado que mantiene una relacin especial con el tag que lo encierra. Tag <f:loadBundle> Este tag permite manejar el modelo de i18N especificando un recurso ( bundle ) para el locale de la vista actual. El contenido del bunle es cargado en un Map.
CIBERTEC
141
Tag <f:metadata> Este tag encapsula un conjunto de elementos que se utilizan para especificar la metadata para una vista Facelet. En consecuencia debe ser un tag hijo del tag f:view. En el siguiente ejemplo, se especifica que el valor del parmetro que viene en el request HTTP con el nombre foo ser automticamente recuperado y cargado dentro de la propiedad bean.foo.
Tag <f:param> Se utiliza para sustituir parmetros cuando se emplea dentro de un tag <h:outputFormat> o para agregar valores query-string a un URL cuando se utiliza dentro de <h:commandLink> o <h:outputLink> Tag <f:phaseListener> Sirve para registrar una instancia de PhaseListener sobre el UIViewRoot en donde se encuentra anidado el tag. Tag <f:selectItem> Agrega un componente hijo de tipo UISelectItem al componente UIComponent ms cercano. Ejemplo:
Tag <f:selectItems> Este tag ubica al componente padre UIComponent ms cercano y crea un nuevo UISelectItems vinculndolo a dicho componente padre.
CIBERTEC
142
Ejemplo 1: ColoresMap es un mapa (Map) a partir del cual se carga un listado de colores.
Ejemplo 2: Ahora la lista de colores se toma desde una Collection.
Tag <f:setPropertyActionListener> Este tag permite colocar un valor directamente en un atributo de un backing bean. Ejemplo:
Tag <f:subview> Sirve para crear una subvista. Es til con JSP pero no tiene mayor trascendencia en facelets. Sirve como contenedor para todos los componentes UIComponents usados dentro de una pgina anidada que se incluye va <jsp:include> o va JSTL con <c:import>. Ejemplo:
CIBERTEC
143
Tag <f:validateBean> Este tag se integra al JSR 303 que especifica el Bean Validation API. El uso de este tag causada que una instancia de javax.faces.validator.BeanValidator se registre en el componente padre. Ejemplo:
Tag <f:validateDoubleRange> Sirve para generar validaciones sobre el componente padre. Soporta atributos de mximo y mnimo. Ejemplo:
Tag <f:validateLength> Sirve para generar validaciones sobre Strings en el componente padre. Soporta atributos de mximo y mnimo. Ejemplo:
Tag <f:validateLongRange>
CIBERTEC
144
Sirve para generar validaciones sobre el componente padre. Soporta atributos de mximo y mnimo. Ejemplo:
Tag <f:validateRegex> Este tag crea una instancia de javax.faces.RegularExpression y la asocia al componente padre para efectuar las validaciones. Ejemplo:
Tag <f:validateRequired> Este tag genera una instancia de javax.faces.Required y lo asocia al componente padre. La funcionalidad es la misma que si se configura el atributo required en true para un componente editable. Ejemplo:
Tag <f:validator> Genera un validador y lo asocia al componente padre. Ejemplo:
Tag <f:valueChangeListener> Registra un Listener asociado a la instancia del component padre. Ejemplo:
CIBERTEC
145
Tag <f:verbatim> Este component es til para JSP, pero no tiene mayor propsito con JSF Faceleters. Crea y registra una instancia hija de UIOutput en el componente asociado ms cercano. Sirve para anidar contenido en HTML, XML o cualquier otro lenguaje de marcas. Ejemplo:
Tag <f:view> Sirve para crear una vista. La vista sirve como contenedor para todos los componentes JSF utilizados en una pgina. Tag <f:viewParam> Permite que de forma declarative se registren parmetros como metadata asociada a la vista padre por lo que debe ser un componente hijo del tag <f:metadata>. El objetivo es soportar vistas favoritas que puedan ser invocadas via mtodo GET. Ejemplo:
2.4 LIBRERA HTML El namespace con el que se declara es http://java.sun.com/jsf/html y se le asigna el prefijo h. Tag <h:body> Es el tag encargado de mostrar los cdigos HTML <body> y </body> en una vista. Tag <h:head> Es el tag encargado de mostrar los cdigos HTML <head> y </head> en una vista. Se utiliza para que JSF pueda incluir hojas de estilo y javascripts generados por los tags <h:outputScript> y <h:outputStylesheet>
CIBERTEC
146
Tag <h:form> Es el tag que muestra un formulario para captura de datos. Todos los tags que se encuentren en el interior sern enviados con el formulario. Configura un atributo action apuntando a un URL que define la accin a ejecutar y el atributo method configurado en POST.
Tag <h:outputScript> Este tag muestra el tag HTML <script> con el atributo src determinado por los valores de name y library ingresados. La especificacin de JSF 2.0 requiere que los recursos de la aplicacin web sean colocados debajo del folder resources.
Tag <h:outputStyleSheet> Este tag muestra el tag HTML <link> con el atributo href determinado por los valores de name y library ingresados. Adems, muestra el atributo rel con los valores de stylesheet y text/css.
CIBERTEC
147
Tag <h:inputText> Muestra un campo de entrada de datos con el tag HTML <input> y el atributo type configurado en text.
Tag <h:inputTextarea> Muestra un campo de entrada de datos con mltiples lneas usando el tag HTML <textarea>.
Tag <h:inputSecret> Este tag muestra una caja de ingreso de datos del tipo password, es decir, los valores no se muestran al usuario.
CIBERTEC
148
Tag <h:inputHidden> Este tag genera un campo oculto dentro de la pgina. El componente no se visualiza al momento del render en el cliente. Tag <h:outputLabel> Este componente muestra una etiqueta de texto usando el tag HTML <label> y puede de manera opcional, ser especificada para un campo de ingreso (con el atributo for).
Tag <h:outputLink> Este componente muestra un enlace usando el tag HTML <a> con el atributo href configurado con el valor del componente.
Si se desea enviar parmetros en el link se puede usar la forma siguiente:
Tag <h:outputFormat> Muestra un texto formateado. El texto se muestra dentro de un tag HTML <span> si es que se indica el atributo id o algn atributo de estilo.
CIBERTEC
149
Tag <h:outputText> Muestra el valor del componente como texto dentro de una pgina.
Tag <h:commandButton> Este componente muestra un botn con el tag HTML <input> y el type configurado a submit, reset o image. Puede ser asociado a un backing bean o a un ActionListener para manejar eventos. La etiqueta del botn se especifica con el atributo value o con el url de la imagen. Adicionalmente soporta la obtencin del texto desde un Bundle para efectos de manejar i18N. El tag emplea el mtodo POST para enviar la data al servidor. El atributo type puede ser submit o reset. El atributo action se asocia a un mtodo de algn backing bean.
Tag <h:button> Este component es similar a <h:link> y fue introducido en JSF 2 para permitir el soporte a vistas Facelets que puedan ser marcadas como favoritas (bookmarks). Se presenta un problema si los navegadores tiene el javaScript deshabilitado debido a que el tag genera un evento onclick para manejar la navegacin va window.location.href. Ejemplo:
CIBERTEC
150
Este cdigo genera el siguiente HTML:
Tag <h:message> Este componente muestra los mensajes generados por JSF para el componente identificado por el atributo for.
Tag <h:messages> Muestra todos los mensajes almacenados. Si el atributo globalOnly est en true, muestra los mensajes sin el identificador de componente. Utiliza celdas HTML de una tabla si es que se configura el atributo layout en table.
Tag <h:graphicImage> Este componente sirve para mostrar una imagen utilizando el tag HTML <img> con el valor del atributo src apuntando al valor del componente (value) o al atributo url. En JSF 2 se agregan los atributos library y name para soportar imgenes desde libreras de recursos.
CIBERTEC
151
Otra forma es usando el atributo url:
Tag <h:selectOneListBox> Este componente muestra un <select> HTML cuyo tamao de lista es igual a la cantidad de elementos <option>. Slo permite la seleccin de un elemento.
Tag <h:selectOneMenu> Este componente muestra un <select> HTML cuyo atributo name es el ID del componente y el atributo size es 1. Cada opcin del men se muestra como un elemento <option>. Si la opcin se marca como deshabilitada, se agrega el atributo disabled.
Tag <h:selectOneRadio> Este component muestra una table HTML con un conjunto de radio buttons entre los cuales el usuario puede escoger.
CIBERTEC
152
Tag <h:selectBooleanCheckbox> Este component muestra un element HTML <input> de tipo checkbox.
Tag <h:selectManyCheckbox> Muestra una tabla con un conjunto de checkboxes
Tag <h:selectManyListBox> Muestra un tag HTML de tipo <select> pero permitiendo selecciones mltiples.
CIBERTEC
153
Tag <h:selectManyMenu> Muestra un tag HTML de tipo <select> permitiendo selecciones mltiples. El tamao de visualizacin es 1 (atributo size).
Este componente esta diseado para situaciones en las que se necesita mostrar un men de opciones al usuario para permitirle seleccionar mltiples opciones pero utilizando un men que slo muestra una opcin a la vez. La principal diferencia entre los select y los menus en JSF es el atributo size. Los menus siempre tienen el size en 1 mientras que las listas pueden tener el tamao variable. NOTA: Este componente no se visualiza correctamente en todos los navegadores. Tag <h:panelGrid> Es un contenedor tabular para otros componentes y es visualizado como una tabla HTML. Los componentes hijos son visualizados como celdas dentro de la tabla.
CIBERTEC
154
Tag <h:panelGroup> Este componente crea un contenedor para agrupar a un conjunto de componentes bajo un padre. Al visualizar los componentes hijos, se usa el tag HTML <span>. Tag <h:dataTable> Este componente genera un contenedor tabular para otros componentes hijos. Tag <h:column> Este tag sirve como hijo del tag <h:dataTable>.
2.5 LIBRERA DE TEMPLATES El namespace con el que se declara es http://java.sun.com/jsf/facelets y se le asigna el prefijo ui. Sus tags han sido explicados en el tema de Facelets y Templates.
2.6 LIBRERA DE COMPONENTES COMPUESTOS El namespace con el que se declara es http://java.sun.com/jsf/composite asigna el prefijo composite. y se le
Esta librera slo se declara y utiliza en pginas que requieren el empleo de componentes compuestos JSF.
CIBERTEC
155
Resumen
La librera CORE: se asocia al namespace f: y proporciona utilidades para validacin, conversin, internacionalizacin, etc. La librera HTML: se asocia al namespace h: y est diseada especficamente para clientes HTML. La librera de tags para Plantillas FACELET: asociada al namespace ui: permite agregar funcionalidades de plantillas y formatos. Fue introducida en JSF 2.0. La librera de tags para Componentes Compuestos: introducida tambin con JSF 2.0, se registra bajo el namespace cc:. Si desea saber ms acerca de estos temas, puede consultar la siguiente bibliografa: The Complete Reference : Java Server Faces 2.0 Captulos 7 y 16 . Tambien puede consultar el siguiente URL: http://javaserverfaces.java.net/users.html Aqu hallar la documentacin de las libreras de tags del proyecto Mojarra.
CIBERTEC
156
CIBERTEC
157

TEMARIO
Tema 3: Conversiones, Validaciones y Eventos 3.1. 3.2. 3.3. 3.4. 3.5. Introduccin El sistema de Conversin de JSF El sistema de Validacin de JSF El sistema de Mensajes de JSF El modelo de Eventos de JSF
Los alumnos desarrollan aplicaciones utilizando JSF y aplicando los tags que proporcionan las libreras estndares. Sobre ello, aplican validaciones y conversiones.
CIBERTEC
158
TEMA 3: CONVERSIONES, VALIDACIONES Y EVENTOS

3.1 INTRODUCCIN JSF proporciona componentes para manejar los aspectos de conversin y validacin en el desarrollo de aplicaciones: Conversin: la realizan los Converters y garantiza que los datos sean del tipo esperado. Los converters implementan la interfaz javax.faces.convert.Converter. Validacin: la realizan los validators para garantizar que los datos sean vlidos en funcin a las restricciones de la aplicacin. Los validators son implementaciones de la interfaz javax.faces.validator.Validator.
Es importante conocer que los converters al realizar una transformacin de datos, requieren ser asociados tanto a componentes de entrada como de salida. Mientras que los validators slo se asocian a componentes de entrada. Adicionalmente, JSF proporciona un sistema de mensajes que permite a los desarrolladores controlar la visualizacin de los mensajes de conversin y validacin en las pginas, de una manera flexible utilizando uno o ms tags de tipo <h:message> o <h:messages>.
3.2. EL SISTEMA DE CONVERSIN DE JSF En la fase denominada Apply Request Value es justamente donde se ejecuta la conversin de los valores que llegan desde el formulario hacia el tipo de dato apropiado. Si la conversin es exitosa, los valores pasan a ser validados. Todos los objetos que cumplan la funcin de converters deben implementar a la interfaz javax.faces.convert.Converter. Esta interfaz tiene dos mtodos:
Donde: El parmetro context es la instancia FacesContext del request. El parmetro component es el componente cuyo valor ser convertido. El parmetro value es el valor a ser convertido. El mtodo getAsObject es invocado durante el procesamiento de entrada, para convertir los valores String que llegan en el request, al tipo de dato deseado.
CIBERTEC
159
El mtodo getAsString es invocado durante la fase de salida para mostrar los valores en formato de String en cualquiera de las tecnologas de rendering que soporta el cliente. Si se lanza una excepcin de tipo ConverterException, el componente se marca como invlido y se coloca un mensaje en el FacesContext. Los convertidores estndares son:
Todos los converters se puede llamar usando el tag <f:converter> y especificando el ID, a excepcin de DateTimeConverter y NumberConverter que tienen sus propios tags: <f:convertDateTime> y <f:convertNumber>. La forma implcita de conversin se realiza cuando JSF conoce el tipo de dato del valor. Por ejemplo, asumiendo que age es un atributo de tipo Integer del managed bean user, en el siguiente caso la conversin es implcita:
La forma explcita es cuando se usan los tres tags que proporciona la librera core de JSF. Tag #1: <f:convertDateTime>
Donde:
CIBERTEC
160
El dateStyle puede ser: short, mdium, long, full o default. El valor de type puede ser: date, time o both (default). El valor de binding es una expresin que apunta a un mtodo de una clase que implementa la interfaz javax.faces.convert.Converter.
Tag #2: <f:convertNumber>
Donde: type puede ser number, currency o percentage. currencyCode es el cdigo ISO 4217 de las monedas. Por ejemplo, USD es para los dlares americanos y EUR para el euro. Para la moneda peruana se tiene el cdigo PEN. currencySymbol se puede especificar para indicar el smbolo de la moneda a utilizar (pero se debe tener en cuenta que esto es vlido con JDK 1.4 o superior). El atributo currencyCode toma preferencia sobre este. groupingUsed es un flag boolean que sirve para indicar cuando se debe usar un delimitador. El valor de binding es una expresin que apunta a un mtodo de una clase que implementa la interfaz javax.faces.convert.Converter. Tag #3: <f:converter>
Donde: converter-id es el valor registrado en el archivo faces-config.xml de la aplicacin. El valor de binding es una expresin que apunta a un mtodo de una clase que implementa la interfaz javax.faces.convert.Converter.
Para vincular un Componente UI con un converter, simplemente hay que anidar el converter dentro del tag:
CIBERTEC
161
3.3 EL SISTEMA DE VALIDACIN DE JSF La interfaz javax.faces.validator.Validator es el ncleo del sistema de validaciones de JSF. Todos los objetos que cumplan la funcin de validadores deben implementar esta interfaz. Dicha interfaz tiene un nico mtodo:
Este mtodo es invocado durante la fase de Apply Request Values si el componente est marcado como Immediato o durante la fase de Process Validations en caso contrario. Antes de invocar al mtodo, JSF marca al componente como invlido. El mtodo lanza la excepcin ValidatorException si ocurre un error durante la validacin: se almacena un mensaje en el FacesContext. En caso no ocurran errores, el componente recin se marca como vlido. A diferencia de los converters, los validators se registran por validator-id debido a que el concepto de validacin no est asociado al tipo del objeto. Adicionalmente, JSF proporciona la facilidad de usar el atributo required en los tags. Si esta propiedad est presente, se ejecutan las validaciones. Los validadores estndares son: Validator-ID javax.faces.DoubleRange Tag Handler f:validateDoubleRange Descripcin Valida que el tipo de dato sea java.lang.Double y se encuentre dentro del rango especificado. Valida que el tipo de dato sea String y que tenga la longitud mnima especificada en el parmetro. Valida que el tipo de dato sea java.lang.Long y se encuentre dentro del rango especificado. Sirve para indicar que el valor sea validado por el framework de validacin EE. Permite el uso de expresiones regulares
javax.faces.Length
f:validateLength
javax.faces.LongRange
f:validateLongRange
javax.faces.Bean
f:validateBean
javax.faces.RegularExpression f:validateRegex
CIBERTEC
162
javax.faces.Required
f:validateRequired
Tiene la misma funcionalidad que el atributo required : campo obligatorio.
Para que JSF no valide campos que estn vacos se debe agregar lo siguiente al web.xml:
Los validadores se pueden asociar a los componentes UI de dos maneras: usando tags de la librera core o utilizando el MethodBinding. Usando los tags de la librera core: <f:validateDoubleRange>, <f:validateLongRange> y <f:validateLength>
Usando el MethodBinding:
En este caso, se asocia a un mtodo del managed bean user:
3.4 EL SISTEMA DE MENSAJES Los mensajes de error generados en la validacin o en la conversin fluyen hacia el usuario mediante la clase javax.faces.application.FacesMessage, el contexto FacesContext y los componentes UIMessage y UIMessages. La clase FacesMessage encapsula los mensajes que describen los problemas de conversin y validacin. Posee tres propiedades interesantes: severity : que puede ser INFO, WARN, ERROR, FATAL. summary: contiene los mensajes de forma comprensible para el usuario. detail: contiene los mensajes de forma comprensible para el usuario.
CIBERTEC
163
La instancia de FacesContext mantiene dos colecciones de instancias FacesMessage que pueden ser accedidas por diferentes formas del mtodo getMessages(): Una de mensajes asociados con un componente. La otra de mensajes que no estn asociados con el componente. El mtodo getMessages() de la instancia FacesContext: Sin argumentos retorna un Iterator de todos los mensajes (estn asociados o no con el componente). Con el argumento clientId retorna slo los mensajes asociados con ese clientId. Si el clientId es NULL, retorna los mensajes que no estn asociados con un valor especfico de clientId.
3.4.1 EN QUE MOMENTO SE GENERAN LOS MENSAJES ? Existen tres momentos dentro del ciclo de vida del request cuando los componentes generan instancias de FacesMessage y las agregan al FacesContext: 1. Cuando falla una conversin. 2. Cuando falla una validacin. 3. Cuando los datos, una vez convertidos y validados no pueden ser actualizados en el modelo durante la fase denominada Update Model Values. En el caso de la conversin, un error significa el lanzamiento de la excepcin ConverterException. La severidad de ste error siempre es ERROR. El converter tiene dos opciones: 1. No enva parmetros al ConverterException, en cuyo caso, se genera un FacesMessages con el mensaje conversin failed. 2. Se enva como parmetro una propiedad message, cuyo valor se utiliza como la propiedad detail de FacesMessage. En el caso del validador, un error significa el lanzamiento de la excepcin ValidatorException, el cual siempre enva un FacesMessage en su constructor. La severidad de la excepcin siempre est a nivel de ERROR. En el caso de la actualizacin del modelo, cuando se lanza una excepcin EL, se examina el mensaje de la excepcin. Si no es null, se crea un FacesMessage con el mensaje como atributo summary. Si es null, se crea un FacesMessage con un mensaje de error genrico.
3.4.2 COMO SE AGREGAN LOS MENSAJES ? Se tiene que agregar al FacesContext
CIBERTEC
164
3.4.3 COMO SE VISUALIZAN LOS MENSAJES ? Existen dos componentes estndares que permiten visualizar los mensajes: UIMessages y UIMessage. En base a esos componentes, el kit de HTML tiene dos renderers: javax.faces.Messages y javax.faces.Message respectivamente, de manera tal que los tags a emplear son: <h:messages> y <h:message> que se encuentran en la librera html. a) Mostrando mensajes para un componente especfico: al tag <h:message> se le debe proporcionar el atributo for para indicar el componentId acerca del cual se mostrarn los mensajes. De esta manera, el desarrollador puede colocar los mensajes en cualquier lugar de la pgina. b) Mostrando mensajes para todos los componentes: si se coloca el tag <h:messages> en algn lugar de la pgina, todos los mensajes que se encuentran en el FacesContext son mostrados a menos que se configure el atributo globalOnly (en cuyo caso slo se muestran los mensajes que no estn asociados a un determinado componente). Adems, se puede especificar el atributo layout con los valores de list (los mensajes se muestran como una lista HTML sin orden alguno ) o table ( los mensajes se muestran como tabla HTML). c) Personalizando los mensajes: el contenido de los mensajes por defecto puede ser poco claro para efectos de una aplicacin. Es posible proporcionar un Resource Bundle ( archivo .properties) con los mensajes que se desea manejar y de esa forma sobre escribir los mensajes por defecto de JSF. Para ello se debe agregar el siguiente bloque al archivo faces-config.xml:
CIBERTEC
165
Tener en cuenta que este archivo requiere que los tags vayan en cierto orden (debido al DTD). En este ejemplo se est indicando que el archivo de mensajes se llama MyMessages.properties y que los idiomas soportados son Espaol e Ingls. Adems, se debe tener en cuenta que para sobre escribir los mensajes por defecto, el archivo de mensajes debe tener como key los messagesID del framework y como value, los textos que se desea para la aplicacin.
Algunos de los messageID estndares que pueden ser sobre escritos son: javax.faces.component.UIInput.CONVERSION javax.faces.component.UIInput.REQUIRED javax.faces.component.UISelectOne.INVALID javax.faces.component.UISelectMany.INVALID javax.faces.converter.BigDecimalConverter.DECIMAL javax.faces.converter.BigIntegerConverter.BIGINTEGER javax.faces.converter.BooleanConverter.BOOLEAN javax.faces.converter.ByteConverter.BYTE javax.faces.converter.CharacterConverter.CHARACTER javax.faces.converter.DateTimeConverter.DATE javax.faces.converter.DateTimeConverter.TIME javax.faces.converter.DateTimeConverter.DATETIME javax.faces.converter.DateTimeConverter.PATTERN_TYPE javax.faces.converter.DoubleConverter.DOUBLE javax.faces.converter.FloatConverter.FLOAT javax.faces.converter.IntegerConverter.INTEGER javax.faces.converter.LongConverter.LONG javax.faces.converter.NumberConverter.CURRENCY javax.faces.converter.NumberConverter.PERCENT javax.faces.converter.NumberConverter.NUMBER javax.faces.converter.NumberConverter.PATTERN javax.faces.converter.ShortConverter.SHORT javax.faces.converter.STRING javax.faces.validator.NOT_IN_RANGE javax.faces.validator.DoubleRangeValidator.MAXIMUM javax.faces.validator.DoubleRangeValidator.MINIMUM javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE javax.faces.validator.DoubleRangeValidator.TYPE javax.faces.validator.LengthValidator.MAXIMUM javax.faces.validator.LengthValidator.MINIMUM javax.faces.validator.LongRangeValidator.MAXIMUM javax.faces.validator.LongRangeValidator.MINIMUM
CIBERTEC
166
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE javax.faces.validator.LongRangeValidator.TYPE
Se puede editar el archivo messages.properties que se encuentra en el jar de las APIs de JSF y ver todas las llaves disponibles. 3.5 MODELO DE EVENTOS DE JSF JSF proporciona un modelo de programacin basado en eventos que es muy similar al que se utiliza en el desarrollo de aplicaciones Swing o AWT. Esto permite un mejor control de interfaces de usuario complejas debido a que los componentes de dicha interfaz publican cambios en sus estados ( eventos) hacia un conjunto de objetos que actan como listeners y que ejecutan las tareas requeridas. Hay dos tipos de eventos: Los eventos de aplicacin Los eventos de ciclo de vida
Los eventos pueden ser publicados a lo largo del ciclo de vida de una aplicacin JSF. Este ciclo de vida puede ser dividido en tres etapas: inicio (start-up). ejecucin de procesamiento del ciclo de vida del request. La mayor parte del tiempo, la aplicacin se ejecuta en esta etapa. finalizacin (shutdown).
CIBERTEC
167
Los eventos publicados durante la etapa de procesamiento del ciclo de vida de los request se muestra en el siguiente grfico:
Los eventos que ocurren durante el start-up son: PostConstructApplicationEvent Los eventos que ocurren durante el Shutdown son: PreDestroyApplicationEvent Los eventos que ocurren en cualquier momento del ciclo de vida de la aplicacin: ExceptionQueuedEvent PostConstructCustomScopeEvent PreDestroyCustomScopeEvent PostConstructViewMapEvent PreDestroyViewMapEvent PostAddToViewEvent PreRemoveFromViewEvent 3.5.1 EVENTOS DE APLICACIN Tipo de Evento ActionEvent Momento en el que se procesa Al completar la fase denominada Invoke Application a menos que se use el flag immediate con el valor true en cuyo caso se procesa al final de la fase Apply Request Value. Al finalizar la fase de Process Validations a menos que el flag immediate est en true, en cuyo caso se procesa al final de la fase Apply Request Value.
ValueChangeEvent
CIBERTEC
168
En general, para manejar eventos Faces se puede escribir una clase listener que implemente la interfaz apropiada ( javax.faces.event.ActionListener ) y que se vincule al componente ( en este caso, al UIComponent). Para Action Events sin embargo, se puede escribir: o un mtodo en una clase Action o un mtodo en una clase Listener. La explicacin es la siguiente: a) Un action method es un simple mtodo Java que tiene lugar en un managed bean, no tiene argumentos y retorna un String. Estos action methods son manejados por un ActionListener, que por defecto toma el valor del String y lo enva al NavigationHandler con el fin de determinar el siguiente paso de navegacin. Un action method se asocia a un UIComponent con el atributo action. Ejemplo:
b) Si no se requiere navegacin, se utilizan los action listener method, que es un mtodo que simplemente se ejecuta y que no devuelve resultados ( retorna void). Se asocia a un UIComponent con el atributo actionListener.
Los Value Change Events son eventos que se emplean para indicar que el valor de un componente UI ha cambiado. Generalmente se emplea para componentes que implementan las interfaces ValueHolder o EditableValueHolder.
CIBERTEC
169
Al igual que los action events, los value change events pueden manejarse de la misma manera.
Sin embargo, debe tenerse presente que el evento ocurre cuando se hace el submit del formulario. Es ms, el evento sucede en la fase de Process Validations. Un siguiente envo del formulario sin alterar el valor, no genera que se dispare el evento debido a que no ha cambiado el valor del campo. Si se agrega el atributo immediate y se configura en true, se puede disparar el evento de cambio en la fase de Apply Request Values.
Para personalizar los Listeners se debe tener en cuenta que: Si se implementa la interfaz ActionListener se debe anidar dentro del componente UI el siguiente tag:
Si se implementa la interfaz ValueChangeListener se debe anidar dentro del componente UI el siguiente tag:
3.5.2 EVENTOS DE FASE Los eventos de fase ( o Phase Events ) se procesan entre cada fase del procesamiento de ciclo de vida de un request. Se puede crear un Listener simplemente implementando la interfaz PhaseListener. Esta interfaz posee tres mtodos que deben ser implementados: beforePhase() afterPhase() getPhaseId()
CIBERTEC
170
Los mtodos beforePhase() y afterPhase() se ejecutan para todas las fases del ciclo de procesamiento de un request, por tanto, si se desea ejecutar alguna lgica especial en determinada fase, se deber obtener el ID de la fase y en base a condiciones, controlar el flujo del cdigo. El mtodo getPhaseId() sirve para determinar a que fase est asociado el listener. Cuando se usa para cualquier fase retorna el valor ANY_PHASE:
Finalmente, el listener debe registrarse en el faces-config.xml :
3.5.3 EVENTOS DE SISTEMA Este tipo de eventos fueron introducidos con la especificacin JSF 2.0 y proporcionan mayores detalles que los ofrecidos por los eventos de fase.
CIBERTEC
171
Resumen
Dentro del procesamiento del ciclo de vida de un request, lo primero que se ejecuta es la conversin de datos que llegan desde el request. SI todo funciona bien, recien se ejecuta la validacin de los mismos. Un conversor personalizado implementa la interfaz javax.faces.convert.Converter. El mtodo getAsObject se aplica cuando se reciben los datos del request y el mtodo getAsString se aplica para devolver la visualizacin al cliente. Un validador personalizado implementa la interfaz javax.faces.validator.Validator. Tiene un nico mtodo validate en donde se debe escribir la lgica de validacin deseada. Los mensajes de error se muestran con los tags <h:message> y <h:messages>. Para personalizarlos, se requiere definir el archivo de recursos en el facesconfig.xml Los eventos ms utilizados en JSF estn relacionados con la pulsacin de botones o el cambio de valores en la pgina: ActionEvent y ValueChangeEvent.
CIBERTEC
172
CIBERTEC
173

TEMARIO
Tema 4: Tpicos avanzados de JSF I 4.1. 4.2. 4.3. JSF y AJAX Integracin JSF + JPA Empleando otras implementaciones de JSF
Los alumnos desarrollan aplicaciones JSF incorporando funcionalidades de tipo Ajax en la interfaz de usuario. Los alumnos integran las aplicaciones JSF con el framework JPA.
CIBERTEC
174
TEMA 4: TPICOS AVANZADOS DE JSF I

4.1 JSF y AJAX JSF se constituye en el mejor framework que se integra y facilita el uso de las capacidades de Ajax. El concepto de AJAX corresponde a un conjunto de tecnologas ( Hojas de estilo, JavaScript, Document Object Model , etc. ) que permiten ejecutar llamadas asncronas al servidor y procesar la respuesta modificando el rbol DOM que se almacena en el navegador. JSF proporciona dos maneras de trabajar con AJAX, la primera forma es mediante un tag nuevo identificado como <f:ajax> mediante el cual no hay que preocuparse acerca del uso de javaScript. La segunda forma es el uso de una API de JavaScript llamada jsf:ajax.request() que proporciona un puente estndar para las peticiones de tipo Ajax. 4.1.1 TAG <f:ajax> JSF proporciona un tag para el manejo de llamadas AJAX: <f:ajax>, que al igual que otros tags de la librera core, no puede ser empleado aisladamente. Es decir, debe ser anidado o debe contener a otros tags que se asocien con un Componente UI. Los atributos que acepta este tag pueden dividirse en dos: Atributos que actan sobre el server-side Atributo Valor execute Lista de IDs separada por comas, expresin que se evala como lista o palabra reservada. render Indica los valores a ser enviados en el POST. Lista de IDs separada por comas, expresin que se evala como lista o palabra reservada. Indica la porcin de la vista ( subtree ) a ser renderizada. Expresin que invoca a un mtodo Java. Dicho mtodo tiene la siguiente firma: void mtodo( AjaxBehaviourEvent abe ) Si el valor no es nulo, el mtodo es invocado durante la fase denominada Invoke Application en el procesamiento del ciclo de vida del request. true/false o alguna expresin que devuelva uno de esos valores. true/false o alguna expresin que devuelva uno de esos valores. Si es true, el tag est deshabilitado.
listener
immediate disabled
Atributos que actan sobre el client-side Atributo
Valor
CIBERTEC
175
event
String que contiene uno de los nombres de eventos soportados. Cuando sucede el evento, se enva un request de tipo POST hacia el servidor. Nombre ( o Expresin que devuelve un nombre ) de una funcin JavaScript que acepta un argumento y que maneja el status del request/response. Nombre ( o Expresin que devuelve un nombre ) de una funcin JavaScript que acepta un argumento y que maneja el status del request/response. Si no es especifica y el modo Development est configurado, slo la implementacin JSF Mojarra muestra un dilogo de alerta.
onevent onerror
Por default, todos los componentes UI de captura de datos disparan el evento valueChange.
Ejemplo:
4.1.2 JAVASCRIPT ESTNDAR Todas las implementaciones de JSF 2 deben contener una librera denominada javax.faces la cual contiene un Script llamado jsf.js que expone una serie de APIs estndares para ejecutar las invocaciones Ajax. Existen dos objetos principales dentro del javaScript: ajax y til. El objeto ajax tiene las funciones siguientes:
Funcin JavaScript addOnError(callback) addOnEvent(callback) request(source, event, options) response( request, context )
Significado Proporciona la misma implementacin que el atributo onerror del tag <f:ajax> Proporciona la misma implementacin que el atributo onevent del tag <f:ajax> Proporciona la misma implementacin de la parte del request del tag <f:ajax> Proporciona la misma implementacin de
CIBERTEC
176
manejo del response que el tag <f:ajax> La funcin ms importante es request, la cual toma tres parmetros: source : es el elemento DOM que dispara el requerimiento Ajax. Normalmente su valor es this. event: es opcional y corresponde al evento DOM que dispara el requerimiento Ajax. Se usa normalmente para recuperar informacin adicional sobre el evento ( por ejemplo que tecla fue presionada). options: tambin es opcional. Contiene una lista de llaves y valores segn la relacin siguiente: execute : lista de IDs (separadas por comas) a ser procesada durante el request. render : lista de IDs (separadas por comas) a ser reemplazados durante el response. onevent : Funcin JavaScript a ser invocada para el evento. onerror : Funcin JavaScript a ser invocada si hay un error. params : parmetros a ser includos en el request. Las opciones ms importantes son execute y render y bajo JSF 2 permiten el concepto de vista parcial: es un mecanismo que permite que el procesamiento de ciclo de vida de un request se ejecute sobre uno o ms componentes. Slo los componentes identificados en el request sufren el proceso de validacin, conversin y actualizacin del modelo. De igual forma, en el render, slo los componentes indicados sufren la actualizacin en el rbol DOM sin tener que refrescar toda la pgina. Adicionalmente, en lugar de identificar cada uno de los componentes para el execute y el render, se puede emplear algunos tokens: Token @all @none @this Significado Todos los componentes de la vista Ningn componente ( es el default para el render ) Es el componente que dispara el evento (valor por defecto para execute) Todos los componentes del formulario
@form
Para poder utilizarla la librera JavaScript es preciso incorporar en la pgina Faces el siguiente tag:
Este tag le dice a JSF que coloque el script en la cabecera de la pgina. Luego, al componente UI se le define el atributo correspondiente al evento que se desea manejar:
CIBERTEC
177
En este caso se define el evento onkeypress: cada vez que se pulse una tecla, dicho valor aparecer en el campo con id outNombre.
4.2. INTEGRACIN JSF + JPA Las entidades JPA tambin pueden funcionar como Managed Beans simplemente agregando las anotaciones @ManagedBean y la anotacin de mbito respectivo (por ejemplo @RequestScoped ). Es aconsejable emplear JSF 2 con EJB 3.0 y JPA para que el contenedor de EJBs controle las transacciones. Sin embargo, se puede utilizar directamente JPA pero se debe tener en cuenta que hay que manejar la persistencia y las transacciones de forma manual. Enterprise Java Beans (EJB ) es una arquitectura de componentes Java en el lado servidor que permite el desarrollo rpido y simplificado de aplicaciones portables, distribuidas, transaccionales y seguras basadas en la plataforma Java EE. Java PErsistence API (JPA) es un framework basado en Java que permite manejar datos relacionales en aplicaciones que emplean Java SE o Java EE.
En todo caso, si se emplea la tecnologa de EJB 3.0, se requiere contar con un servidor de Aplicaciones como WebSphere de IBM, Oracle WebLogic o JBoss, dado que Apache Tomcat no soporta contenedores de EJB. Al igual que con Struts 2, se requiere el archivo persistence.xml dentro del folder META-INF y las libreras de la implementacin de JPA ( para el curso es EclipseLink ). Un ejemplo de managed bean con JPA:
CIBERTEC
178
Observe que se controla la excepcin en caso no existan datos: se coloca un mensaje en el contexto de JSF para emplear luego el tag <h:messages /> en la pgina de login. 4.3. EMPLEANDO OTRAS IMPLEMENTACIONES DE JSF Como se haba mencionado, JSF es una especificacin, la cual est soportada por diversas implementaciones. Cada implementacin proporciona un conjunto de tags que presentan determinada funcionalidad, la cual debe ser evaluada segn las necesidades del proyecto. Lo bueno de trabajar con las implementaciones es que en la mayora de casos, todas pueden coexistir dentro de una pgina. Una implementacin ligera que contiene un nico archivo .jar, no requiere configuracin y no tiene dependencias ( a diferencia de Apache MyFaces) es PrimeFaces ( http://www.primefaces.org ). PrimeFaces proporciona un conjunto de componentes muy interesantes con un gran diseo y funcionalidad a la vez que le otorga un tratamiento especial al tema de Ajax como veremos en el siguiente ejemplo. Descargar la librera ( para JSF 2 ) desde el URL de Primefaces ( http://www.primefaces.org/downloads.html ) y configurar el Build Path del proyecto.
CIBERTEC
179
No olvidar de configurar tambin el CLASSPATH del servidor. Si el servidor es Tomcat, debe quedar as:
A continuacin se muestra el encabezado de la pgina XHTM. Note que la librera de PrimeFaces est identificada como p:
CIBERTEC
180
Y el fragmento de cdigo que emplea Tags de PrimeFaces:
El proceso es bastante sencillo: se debe ingresar un ID que ser verificado cuando el usuario presione el enlace de verificacin. Este ID ser validado disparando la accin denominada nickAction del Managed Bean utilizando AJAX. El tag p:ajaxStatus controlar el procesamiento de la peticin AJAX y mostrar u ocultar la figura ajax-loading.gif El cdigo del ManagedBean:
CIBERTEC
181
Y Lo que se debe visualizar en el navegador. Observe el diseo ms elaborado.
CIBERTEC
182
Resumen
JSF 2 soporta Ajax de dos formas: la primera esmediante el uso de la API de JavaScript: jsf,ajax.request(); la segunda forma es mediante el tag <f:ajax> La API de JavaScript poporciona un puente para el manejo de las peticiones ajax y permite un cierto nivel de control. El tag <f:ajax> permite que el programador se olvide del JavaScript. Para integrar JSF con JPA, slo debe configurarse los archivos requeridos por JPA. El resto de temas se manejan con la unidad de persistencia y el EntityManager. Si desea saber ms acerca de estos temas, puede consultar las siguientes pginas. http://java.dzone.com/articles/ajax-jsf-joined Aqu encontrar una explicacin del soporte que JSF brinda al tema de Ajax.
CIBERTEC
183

TEMARIO
Tema 5: Tpicos avanzados de JSF II 5.1. 5.2. Tablas JSF : Facets, dataTable y panelGrid. Mantenimiento de Tablas
Los alumnos desarrollan aplicaciones web con JSF aprovechando las caracteristicas aprendidas sobre el Framework y generando pantallas que manejen datos en formato de tablas.
CIBERTEC
184
TEMA 5: TPICOS AVANZADOS DE JSF II

5.1 TABLAS EN JSF: Tag <f:facet /> Este tag establece que el componente anidado tiene una relacin especial con el componente padre. Un facet representa una seccin identificada con un nombre (el nico atributo que tiene es name) dentro de un componente UI que acta como contenedor. Normalmente se puede observar su utilizacin con componentes UI complejos ( como PanelGrid o DataTable ). Por ejemplo, los ttulos que forman el encabezado de una tabla, en estricto, no forman parte de la relacin con el componente padre, por tanto son candidatos a ser definidos como facets. Durante el rendering del componente padre, todos los tags facet son mostrados tambin. Ejemplo:
Esto mostrar algo similar a esto ( asumiendo que el valor de beanLogin.clave es TEST1
Tag <h:column /> Este tag sirve como un hijo inmediato del tag <h:dataTable>. Sirve para la definicin de columnas y puede ser equipado con facets llamados header y footer para crear encabezados y pies en las tablas. Los atributos que soporta son: Atributo binding id Tipo Expresion que retorna un valor String Descripcin La referencia a una instancia de opcional un componente UI Identificador del componente opcional
CIBERTEC
185
rendered
boolean
footerClass
String
headerClass
String
Indica si el componente se opcional mostrar durante la fase Render Response. Por defecto es true. Lista (separada por comas) de los opcional estilos que se aplicarn al footer de esta tabla. Lista (separada por comas) de los opcional estilos que se aplicarn al header de esta tabla.
Tag <h:dataTable /> Este tag permite solucionar aquella situacin en la cual el controlador genera una lista de datos de tamao variable y el desarrollador se enfrenta al problema de generar la pgina de salida sin tener la obligacin de usar scripting o hacer iteraciones. Este tag genera una tabla HTML a partir de una coleccin de objetos, donde los componentes anidados ( tag <f:column> ) son responsables de mostrar las columnas de la tabla. Las columnas pueden contener cualquier tipo de componente. El cuerpo de la tabla se muestra dentro del tag HTML <tbody>. Los datos se muestran en celdas y las filas se van agregando a medida que se completa la cantidad de columnas definidas. Los eventos que soporta el componente son: onclick, ondblclick, onkeydown, onkeypress, onkeyup, onmousedown, onmousemove, onmouseout, onmouseover, onmouseup. Los atributos de formato/agrupamiento son: Atributo bgcolor border cellpadding cellspacing first frame Tipo String int int int int String Descripcin El color de fondo de la tabla HTML generada El tamao (en pixels) del borde de la tabla HTML generada El atributo cellpadding de la tabla HTML generada El atributo cellspacing de la tabla HTML generada Primera fila a ser mostrada (inicia en cero ) Especifica en que lado del frame se mostrar la tabla: none above below hsides vsides lhs rhs box border
Opcional Opcional Opcional Opcional Opcional Opcional
CIBERTEC
186
rendered
boolean
rows
int
rules
String
summary
String
var
String
width
String
Indica si el componente se mostrar durante la fase Render Response. Por defecto es true. Determina cuantas filas se mostrarn en la tabla HTML generada Atributo rules pasado a la tabla HTML generada. Indica si se muestra la trama de celdas (como en excel): none groups rows cols all Atributo summary que se enva a la tabla HTML generada. Genera una descripcin pero no es visible en la mayora de navegadores. Es una variable EL que permite iterar sobre los datos. Representa el valor actual en una iteracin sobre el atributo value. Es el atributo width pasado a la table HTML generada ( en pixels es un nmero entero y en porcentaje lleva el smbolo respectivo).
Opcional
Opcional
Opcional
Opcional
Opcional
Opcional
Los atributos core que soporta son: Atributo binding id title value Tipo Expresion que retorna un valor String String String Descripcin La referencia a una instancia de un componente UI Identificador del componente El ttulo del componente. Se pasa a la tabla HTML generada El valor del componente
opcional opcional opcional opcional
Los atributos de estilo: Atributo columnclasses Tipo String Descripcin Lista (separada por comas) de opcional los estilos que se aplicarn a las columnas. Los estilos CSS se aplican repetidamente a las columnas de un componente panelGrid El estilo aplicado a la ltima fila opcional de la tabla. El estilo aplicado a la primera fila opcional
footerclass headerclass
String String
CIBERTEC
187
rowclasses
String
style
String
styleclass
String
de la tabla. Lista (separada por comas) de opcional los estilos que se aplicarn a las filas. Los estilos CSS se aplican repetidamente a las filas de un componente panelGrid Estilo(s) en lnea que se opcional aplicar al componente panelGrid. Estilo(s) CSS que se aplicar al opcional componente panelGrid.
La sintaxis bsica es:
Donde el tipo de dato de value puede ser: Array, List, ResultSet, Result (JSTL), DataModel (JSF). Ejemplo 1:
Asumiendo que el Managed Bean denominado company1 tienen un atributo programmers que devuelve un arreglo de Programadores. Se puede obtener la siguiente pantalla:
Ejemplo 2: Ahora usando encabezados y definiendo facets ( tag <f:facet> )
CIBERTEC
188
Genera la siguiente pantalla:
Ejemplo 3: Usando estilos Note que el encabezado de la tabla tiene un estilo. Asi tambin, las filas pares e impares se manejan con estilos diferentes (obviamente la Hoja de estilos dee estar definida como recurso en la aplicacin ).
CIBERTEC
189
Se mostrar una pantalla similar a la siguiente:
Tag <h:panelGrid /> Este tag genera una tbla HTML que sirve como contenedor para otros componentes. Los componentes hijos son visualizados como celdas. Los eventos que soporta: onclick, ondblclick, onkeydown, onkeypress, onkeyup, Onmousedown, onmousemove, onmouseout, onmouseover y onmouseup. Algunos de los atributos: Atributo bgcolor border Tipo String int Descripcin El color de fondo de la tabla Opcional HTML generada El tamao (en pixels) del borde Opcional de la tabla HTML generada
CIBERTEC
190
cellpadding cellspacing columns frame
int int int String
rendered
boolean
rules
String
summary
String
width
String
El atributo cellpadding de la tabla HTML generada El atributo cellspacing de la tabla HTML generada Nmero de columnas a ser generadas en la tabla HTML Especifica en que lado del frame se mostrar la tabla: none above below hsides vsides lhs rhs box border Indica si el componente se mostrar durante la fase Render Response. Por defecto es true. Atributo rules pasado a la tabla HTML generada. Indica si se muestra la trama de celdas (como en excel): none groups rows cols all Atributo summary que se enva a la tabla HTML generada. Genera una descripcin pero no es visible en la mayora de navegadores. Es el atributo width pasado a la table HTML generada ( en pixels es un nmero entero y en porcentaje lleva el smbolo respectivo).
Opcional Opcional Opcional Opcional
Opcional
Opcional
Opcional
Opcional
Los atributos core que soporta son: Atributo binding id title Tipo Expresion que retorna un valor String String Descripcin La referencia a una instancia de opcional un componente UI Identificador del componente opcional El ttulo del componente. Se pasa opcional a la tabla HTML generada
Los atributos de estilo:
CIBERTEC
191
Atributo columnclasses
Tipo String
footerclass headerclass rowclasses
String String String
style
String
styleclass
String
Descripcin Lista (separada por comas) de los estilos que se aplicarn a las columnas. Los estilos CSS se aplican repetidamente a las columnas de un componente panelGrid El estilo aplicado a la ltima fila de la tabla. El estilo aplicado a la primera fila de la tabla. Lista (separada por comas) de los estilos que se aplicarn a las filas. Los estilos CSS se aplican repetidamente a las filas de un componente panelGrid Estilo(s) en lnea que se aplicar al componente panelGrid. Estilo(s) CSS que se aplicar al componente panelGrid.
opcional
opcional opcional opcional
opcional
opcional
DATAMODEL Un DataModel es una abstraccin arbitraria alrededor de alguna tecnologa que puede ser usada para adaptar una variedad de fuentes de datos para ser empleados por componentes JSF de tal forma que soporten el procesamiento fila por fila por parte de los componentes hijos. La coleccin de datos se modelo como una coleccin de filas de objetos, las cuales pueden ser accedidas por un cursor ( que inicia en cero ) conocido como row index. La API propociona una serie de mecanismoa para posicionar el cursos y recuperar los objetos.
5.2 MANTENIMIENTO DE TABLAS: Se presenta un ejemplo sencillo de mantenimiento usando tablas. Crear una clase Item.java que tenga la siguiente estructura (no olvidar los getter/setter )
CIBERTEC
192
Crear una clase Bean.java ( que es el managed bean de la aplicacin ) que tenga la siguiente estructura. Observe que se utiliza la clase DataModel:
Ahora codificar los mtodos:
CIBERTEC
193
Y el mtodo que controla la edicin:
No olvidar los getter/Setter de tem, model y list. Ahora codificar el FaceLet. La primera parte de la pgina es:
CIBERTEC
194
Hasta aqu se debe mostrar los datos y los botones de edicin y borrado. Ahora codificar la parte de edicin:
CIBERTEC
195
El resultado final es una pantalla similar a la siguiente, que permite la edicin, eliminacin y adicin de elementos en una tabla.
CIBERTEC
196
Resumen
JSF proporciona una manera fcil de visualizar datos sin tener que realizar iteraciones en la pgina, mediante el uso del tag <h:dataTable> Las tablas se pueden refrescar con Ajax o se puede convertir en tablas editables.
CIBERTEC
197
BIBLIOGRAFA
BIBLIOGRAFA
Libros: Struts 2 in Action Donald Brown, Chad Micheal Davis, Scott Stanlick Ed. Manning Press
Starting Struts 2 Ian Roughley Info Q Enterprise Software Development Series.
Pro JPA 2 : Mastering the Java API Persistence Mike Keith , Merrick Schincariol Ed. Apress
The Complete Reference : Java Server Faces 2.0 Chris Schalk , Ed Burns, James Holmes Ed. Mc Graw Hill Beginning JSF 2 APIs and JBoss Seam Kent Ka Iok Tong Ed. Apress
Pginas Web: JSF: http://java.sun.com/javaee/javaserverfaces/reference/docs/index.html
Documentacin de la implementacin JSF Mojarra: http://javaserverfaces.java.net/users.html
JPA:
CIBERTEC
198
http://www.oracle.com/technetwork/articles/javaee/jpa-137156.html http://schuchert.wikispaces.com/JPA+Tutorial+1+-+Getting+Started
Struts 2 http://struts.apache.org/2.2.1/index.html
Libros en el Centro de Informacin HOLMES, JAMES 2007 Struts: the complete reference. 2nd ed. New York: McGraw-Hill (005.133J HOLM2007) MANN, KITO D. 2005 JavaServer Faces in action . Greenwich, CT : Manning (005.133J2EE MANN)
CIBERTEC
199
ANEXOS
ANEXO 1: SOFTWARE REQUERIDO
Este curso requiere las siguientes herramientas de software : Java JDK Entorno integrado de desarrollo o IDE Servidor de Aplicaciones Base de datos Framework Struts 2 Framework JPA Framework JSF
CIBERTEC
200
HERRAMIENTA #1: Java Development Kit

Desde la pgina de Oracle descargar la ltima versin del JDK (Java Development Kit). Se debe considerar que los updates de las versiones son peridicos. Se puede navegar por http://java.sun.com el cual redirecciona a http://www.oracle.com/technetwork/java/javase/downloads/index.html
Para entornos de programacin se requiere el JDK, pero para entornos de produccin basta con el JRE. Ejecutar el instalador y seguir los pasos indicados en el wizard.
CIBERTEC
201
HERRAMIENTA #2: Entorno Integrado de Desarrollo

En un entorno de desarrollo Java, el IDE ( Integrated Development Environment ) es la herramienta de software que nos permite obtener mayor productividad al programar las aplicaciones. En el mercado existen varias opciones disponibles, siendo las ms utilizadas y conocidas: Eclipse IDE : Sitio web http://www.eclipse.org NetBeans : Sitio web http://www.netbeans.org JDeveloper : Informacin disponible en http://www.oracle.com Rational Application Developer: Informacin disponible en http://www.ibm.com
Eclipse IDE :
Descarga Eclipse Helios desde la pgina de la fundacin Eclipse ( http://www.eclipse.org ) buscar la zona de descarga y seleccionar la versin Java EE:
Al terminar la descarga, el .ZIP generado se puede extraer en una carpeta cualquiera (normalmente en la raz de uno de los discos de la PC ). Podemos crear un acceso directo desde el Escritorio apuntando al archivo eclipse.exe
CIBERTEC
202
Rational Application Developer IDE :

Descargar el software IBM Rational Application Developer for WebSphere Software desde la pgina web de IBM: http://www.ibm.com/developerworks/downloads/r/rad/?S_CMP=TRIALS
CIBERTEC
203
HERRAMIENTA #3: Servidor de Aplicaciones

Apache Tomcat
Desde la pgina de la Fundacin Apache ( http://tomcat.apache.org ) debemos obtener el servidor de aplicaciones Tomcat La ltima versin probada en otros tutoriales ha sido la 6.0.20, y al momento de escribir este tutorial la versin disponible es 6.0.29 ( hay una versin 7 en beta ).
Slo es necesario el Core. Descargar el .ZIP y extraerlo en una carpeta.
WebSphere Application Server

Desde la pgina web de IBm se puede descargar el software del servidor de aplicaciones: http://www-01.ibm.com/software/webservers/appserv/was/
CIBERTEC
204
CIBERTEC
205
HERRAMIENTA #4: Motor de Base de Datos

Se necesita un motor de base de datos: En http://www.mysql.com podemos decargar la Base de Datos MySQL ( versin Community Server )
Es preferible descargar la versin NO-INSTALL para que no se afecte el registry de la PC:
Basta con descargar el .ZIP y extraerlo en cualquier carpeta. El servicio de base de datos se activa por lnea de comandos de la manera siguiente:
CIBERTEC
206
Tambin se requiere el Connector o driver JDBC:
Las herramientas de Query Browser y MySQL Administrator han sido reemplazadas por MySQL WorkBench:
De igual forma, seleccionar el .ZIP ( que sea del tipo No Install ) y extraerlo en alguna carpeta de la PC.
CIBERTEC
207
HERRAMIENTA #5: Libreras de Struts 2

Del sitio web de la Fundacin Apache, obtenemos las libreras del framework Struts 2 La ltima versin liberada es la 2.2.1
Escoger una de las opciones de los archivos .ZIP. Con la opcin de Full Distribution est ms que suficiente:
Extraer el contenido del .ZIP en una carpeta de la PC.
CIBERTEC
208
HERRAMIENTA #6: Libreras de JPA

Al ser una especificacin de software, JPA cuenta con algunas implementaciones. Para efectos del manual, se trabaja con la implementacin de EclipseLink, que se puede obtener en la pgina de la Fundacin Eclipse: http://www.eclipse.org/eclipselink/
En la zona de downloads
Seleccionar el Installer ZIP y descargarlo. Descomprimir en ZIP en un folder de la PC.
CIBERTEC
209
HERRAMIENTA #7: Libreras de JSF

Al ser una especificacin de software, JSF cuenta con algunas implementaciones. La que se emplea en el manual es la implementacin de referencia de Java, denominada Proyecto Mojarra y que se puede encontrar en : https://javaserverfaces.dev.java.net/
Descargar el binary bundle y descomprimirlo en algn folder de la PC.
Opcional PrimeFaces : (http://www.primefaces.org/downloads.html
CIBERTEC
210
CIBERTEC
211
ANEXOS
ANEXO 2: CONFIGURAR TOMCAT CON JSF

Si se emplea JSF 2 con Apache Tomcat debe realizarse la siguiente configuracin en el servidor: PASO 1: Descargar las siguientes librerias de la pgina web del proyecto JSF Mojarra. jstl-api-1.2.jar jstl-impl-1.2.jar el-impl-1.1.jar el-api-1.1.jar jsf-api.jar jsf-impl.jar
CIBERTEC
212
PASO 2: Detener el servidor Tomcat. Presionar el cuadrado rojo del lado derecho.
PASO 3: Dar click en el nombre del servidor Tomcat
PASO 4: Dar click en Open Launch Configuration
PASO 5: En el tab Classpath seleccionar User-Entries y agregar la libreras descargadas.
CIBERTEC
213
PASO 6: Adicionalmente agregar las libreras de servlet-api.jar y jsp-api.jar que estn en la carpeta lib del servidor Tomcat.
CIBERTEC

Manual Daw II

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Manual Daw II

Caricato da

Copyright:

Formati disponibili

Desarrollo de Aplicaciones Web II

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

Bibliografa Anexo 1 Anexo 2

197 199 211

DESARROLLO DE APLICACIONES WEB II

Desarrollo de Aplicaciones Web II

Tpicos avanzados de Struts 2

Java Persistence API ( JPA )

Java Server Faces ( JSF )

Gestin de componentes RIA

Tpicos avanzados de JSF

Conversiones, Validaciones y Eventos Introduccin a la API de Persistencia

OR-Mapping con JPA

Componentes de Interfaz de usuario

Relaciones entre entidades

Arquitectura de JSF, Configuracin y estructura bsica

Lenguaje de Consultas JPQL

DESARROLLO DE APLICACIONES WEB II

MANEJO DE TPICOS AVANZADOS CON STRUTS 2

TEMA 1: STRUTS 2 : GESTIN DE COMPONENTES RIA.

DESARROLLO DE APLICACIONES WEB II

<%@taglib prefix=sx uri=/struts-dojo-tags %>

DESARROLLO DE APLICACIONES WEB II

d) Se emplea el primer arreglo que se encuentra. Ejemplo:

e) Si hay un Map, se usa:

Ejemplo: Crear un action que tenga el cdigo siguiente:

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

Ejemplo de tree dinmico:

DESARROLLO DE APLICACIONES WEB II

Crear una clase auxiliar:

DESARROLLO DE APLICACIONES WEB II

Luego proceder a importar el .jar dentro del proyecto.

<%@taglib prefix=sj uri=/struts-jquery-tags %>

DESARROLLO DE APLICACIONES WEB II

El ejemplo est tomado de la pgina de documentacin de Google (ver referencia).

DESARROLLO DE APLICACIONES WEB II

Completar los tags faltantes al final de la pgina. Probar

DESARROLLO DE APLICACIONES WEB II

TEMA 2: TPICOS DE SEGURIDAD Y VALIDACIN EN STRUTS 2

DESARROLLO DE APLICACIONES WEB II

2.2 VALIDACIONES EN STRUTS 2

Struts 2 proporciona dos Interfaces (implementadas por ActionSupport) framework:

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

Ahora, escribir la clase Action ( no olvidar los getter/setter de las variables ):

DESARROLLO DE APLICACIONES WEB II

<Nombre del Action>-validation.xml

DESARROLLO DE APLICACIONES WEB II

Configurar el archivo de validacin: Ejemplo4-validation.xml

DESARROLLO DE APLICACIONES WEB II

Y generar un archivo .properties a nivel de PAQUETE:

Cuyo contenido es:

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

DESARROLLO DE APLICACIONES WEB II

JAVA PERSISTENCE API ( JPA )

TEMA 1: INTRODUCCIN A LA API DE PERSISTENCIA.

Una copia del documento se puede obtener en el enlace: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.1085&rep=rep1&type=pdf

DESARROLLO DE APLICACIONES WEB II

Se puede convertir en entidad, simplemente agregndole las anotaciones : @Entity @Id

FUENTE: JPA 2: Mastering the Java Persistence API, pg 23.