Integración Capa Web de pojo-miniportal (1)

Transcripción

1 Integración Capa Web de pojo-miniportal (1) 1. Cambiar tipo de proyecto maven de "JAR" a "WAR" y actualizar la versión de Tapestry (5.0.18) en las dependencias 2. Añadir configuración del plugin de Jetty al pom.xml 3. Añadir el fichero src/main/jetty/jetty-env.xml a la estructura de vuestro proyecto. En ese fichero se define el nombre del DataSource que Jetty pone accesible por JNDI. La configuración no hace falta tocarla si se utilizan profiles como en los ejemplos (se usan variables). 4. En el pom.xml del proyecto, en la parte de filtrado de recursos, modificar la ruta al fuente de jetty-env.xml (ahora no hacen falta los "../ por no tener submódulos) 5. Copiar src/main/webapp a vuestro proyecto, haciendo las siguientes modificaciones: 1. En WEB-INF/web.xml, especificar el paquete base de la capa Web de vuestro proyecto 2. Adaptar el fichero de configuración de Spring (WEB-INF/springconfig.xml) para el proyecto particular (cambiar la sección Business Objects )

2 Integración Capa Web de pojo-miniportal (y 2) 6. Copiar de src/main/java todo lo que cuelga de es.udc.pojo.miniportal.web a vuestro proyecto, excepto es.udc.pojo.miniportal.web.pages.user (se irán copiando más adelante) 1. Hay que adaptar la clase SessionDispatcher para que trabaje con el UserService de vuestro proyecto 7. Copiar de src/main/resources todo excepto lo que cuelga de es.udc.pojo.miniportal.web.pages.user a vuestro proyecto 8. Copiar a src/main/resources el fichero de configuración de Hibernate que ya teníais (el que teníais en src/test/ resources), y verificar que el fichero de configuración de Spring en webapps/web-inf referencia a ese fichero 9. Cambiar Layout.tml para que no haya enlaces a páginas que no existen (de momento). E.g. haciendo que apunten todas a Index. 10. Arrancar Jetty (mvn jetty:run) y comprobar que es posible acceder a la página principal ( <<proyecto>>) 11. Integrar el resto de páginas (una cada vez)

3 Interfaz gráfica del carrito (1) Es posible pensar en diversas interfaces gráficas para los casos de uso del carrito Las siguientes transparencias muestran tres opciones posibles NOTA: ninguna de las opciones refleja el botón/enlace para iniciar el proceso de compra del carrito, dado que no es relevante para esta discusión Es posible pensar en variantes de cualquiera de las tres opciones, o incluso, en otras opciones distintas 3

4 Interfaz gráfica del carrito (2) Opción 1 Opción 2 Opción 3 4

5 Interfaz gráfica del carrito (3) Todas las opciones Disponen de un enlace para eliminar un producto del carrito Se recomienda usar el componente ActionLink para implementar este enlace Opción 1 Tiene un formulario de actualización de cantidades con tantos campos como productos hay en el carrito Puede implementarse con el soporte integrado de Loop y Form Véase el apartado Forms and Loop Example en la documentación del componente Loop La solución es un poco más compleja que la que muestra la documentación de Tapestry, dado que en la solución mostrada se asume que las líneas son actualizables directamente desde la capa Web, sin necesidad de invocar ningún caso de uso en de la capa modelo 5

6 Interfaz gráfica del carrito (y 4) Opción 2 Tiene un formulario de actualización de cantidad para cada producto del carrito No hace uso del soporte integrado de Loop y Form La implementación es truculenta (e.g. es necesario hacer uso del atributo clientid del componente TextField) Opción 3 Tiene un formulario que permite actualizar la cantidad del producto seleccionado Es la más sencilla, y en consecuencia, la recomendada, tanto si la gestión del carrito se implementa con enfoque Web clásico como con AJAX Se aconseja usar un org.apache.tapestry5.selectmodel (e.g. org.apache.tapestry5.internal.selectmodelimpl) para el parámetro model del componente Select 6

7 Servicios XML (1) Se implementarán como páginas normales que generan XML en lugar de HTML Por defecto, el tipo de contenido que especifica Tapestry en las respuestas HTTP es text/html Los servicios XML deberían utilizar el tipo text/xml en las repuestas HTTP Es preciso usar la sobre la clase página public class XmlService { //... } 7

8 Servicios XML (2) Paso de parámetros El mecanismo habitual para pasar parámetros a una página es el uso del contexto de activación Ejemplo de invocación por GET Clase public class XmlService { //... void onactivate(int par1, String par2) { } //... //... } 8

9 Servicios XML (3) Paso de parámetros (cont) En el caso de parámetros de tipo String o Character, Tapestry necesita codificar algunos caracteres de forma especial, como por ejemplo el espacio en blanco, vocales con tilde, ñ s,etc., dado que en otro caso la URL no estaría en un formato legal Por ejemplo, si el segundo parámetro del ejemplo anterior fuese hello world, sería preciso emplear la URL La codificación que utiliza Tapestry, aunque legal, no sigue ningún estándar, por lo que no resulta conveniente usar el contexto de activación como mecanismo de paso de parámetros en un entorno de integración de aplicaciones con servicios XML 9

10 Servicios XML (4) Paso de parámetros (cont) Por ello, es más conveniente pasar los parámetros a la página como parámetros HTTP Ejemplo de invocación por GET Clase public class XmlService { private org.apache.tapestry5.services.request request; 10

11 Servicios XML (5) Paso de parámetros (cont) Clase página (cont) void onactivate() { String par1asstring = request.getparameter("par1"); String par2asstring = request.getparameter("par2"); //.. } Request.getParameter Devuelve el valor de un parámetro HTTP univaluado Si el parámetro no existe, devuelve null No realiza ningún tipo de conversión automáticamente: los valores se devuelven como String Request.getParameters Idem para parámetros multi-valuados 11

12 Servicios XML (6) Paso de parámetros (cont) Al realizar la invocación, los valores de los parámetros tienen que estar codificados según el formato MIME application/ x-www-form-urlencoded Ciertos caracteres (espacio en blanco, vocales con tilde, ñ s,etc.) se codifican de forma especial No es una restricción de Tapestry, sino la manera estándar de trabajar en HTTP con los valores de los parámetros Esto afecta a los parámetros de tipo String o Character Por ejemplo, si el segundo parámetro del ejemplo anterior fuese hello world, sería preciso usar el valor hello+world Si el cliente es Java, puede usar java.net.urlenconder para realizar la codificación encodedvalue = URLEnconder.encode(value, "UTF-8"); 12

13 Servicios XML (y 7) Si el cliente es.net, puede usar System.Web.HttpUtility encodedvalue = HttpUtility.UrlEncode(value, System.Text.Encoding.UTF8); Cuando se utiliza el navegador como cliente (para pruebas), hay que realizar la conversión a mano si el navegador no lo hace automáticamente E.g. En Firefox 2 para hacer la petición GET del ejemplo anterior habría que introducir E.g. En Firefox 3 sería posible introducir world En el lado servidor (en la clase página) no hay que realizar la decodificación La decodificación de los valores de los parámetros HTTP la hace automáticamente el contenedor de servlets 13

14 AJAX Introducción a AJAX El apartado 4 del enunciado de la práctica introduce el concepto de AJAX Ajax: A New Approach to Web Applications: IntroduccionAJAX.pdf (transparencias 1-13) AJAX en Tapestry Screencast de Howard Lewis Ship demostrando cómo usar el componente Zone: /11/tapestry-5-ajax-screencast.html 14