Ejemplo de Programación con Java EE. Una Tienda Online. Juan Díez- Yanguas Barber. Programación con Java EE 6

Transcripción

1 Ejemplo de Programación con Java EE Una Tienda Online Juan Díez- Yanguas Barber Programación con Java EE 6 Jdyb - Mayo 2011

2 Índice 1.- PREÁMBULO 2.- INTRODUCCIÓN 3.- DISEÑO DEL SISTEMA HERRAMIENTAS UTILIZADAS PATRÓN DE DISEÑO MVC DISEÑO DE LA PERSISTENCIA. PATRÓN DAO DISEÑO DE FILTROS ACCESO A LOS MECANISMOS DE PERSISTENCIA SEGURIDAD DE LA APLICACIÓN 4.- MODELOS DE DATOS USADOS MODELO DE DATOS DE PRODUCTO MODELO DE DATOS PARA EL USUARIO MODELO DE DATOS PARA EL LA CESTA DE LA COMPRA MODELO DE DATOS PARA LOS COMENTARIOS 5.- CONFIGURACIÓN DE LA APLICACIÓN CONFIGURACIÓN DE PERSISTENCIA EN MODO FICHERO CONFIGURACIÓN DE PERSISTENCIA EN MODO DE BASES DE DATOS CONFIGURACIONES MISCELÁNEAS SOBRE LA APLICACIÓN CONFIGURACIÓN DEL SERVIDOR SMTP PARA EL ENVÍO DE S CONFIGURACIÓN DE LAS PLANTILLAS PARA EL ENVÍO DE S LIBRERÍAS NECESARIAS 6.- FUNCIONAMIENTO EN DETALLE DEL SISTEMA ESTRUCTURA DE LA APLICACIÓN DIAGRAMAS DE NAVEGACIÓN DE FILTROS DIAGRAMAS DE NAVEGACIÓN DE LISTENERS FLUJO DE NAVEGACIÓN DE LAS OPERACIONES PÚBLICAS FLUJO DE NAVEGACIÓN PARA OPERACIONES DE USUARIO REGISTRADO FLUJO DE NAVEGACIÓN DE LAS OPERACIONES DEL ADMINISTRADOR SOBRE EL JAVASCRIPT QUE SE HA USADO 7.- SISTEMA DE CONTROL DE VERSIONES 8.- ASPECTOS A MEJORAR Jdyb - Mayo

3 1.- Preámbulo He sido siempre un apasionado de la informática, y desde que comencé mis estudios de Ingeniería Informática esta afición por la materia ha ido creciendo progresivamente. Actualmente he finalizado mis estudios de Ingeniería Técnica en Informática de Sistemas, los que continuaré el próximo año para proseguir con la Ingeniería Superior. El proyecto que aquí les presento viene a ser una asignatura completa, asignatura dedicada a la programación de aplicaciones web, y esta en concreto fue impartida en Java. Cogí desde el principio con mucho ánimo esta asignatura y poco a poco me fue gustando más. Le fui dedicando muchas horas a este proyecto hasta llegar a conseguir un ejemplo lo más realista posible de lo que pudiera ser una tienda online. He disfrutado muchísimo realizando este proyecto no solo porque se trataba de algo nuevo sino porque he adquirido muchos e interesantes conocimientos sobre el lenguaje, si bien es cierto que me queda mucho por aprender de este lenguaje he de reconocer que esto me ha ayudado a dar un paso importante en este continuo aprendizaje. Una vez completado el curso pensé que ya que había dedicado mucho tiempo a este proyecto podría también llegar a más personas y ser de ayuda, por lo que he seguido trabajando en el mismo para publicarlo con una documentación completa. No puedo terminar este texto sin agradecer a Abraham Otero Quintana el interés que ha despertado en mí con este proyecto y los ánimos que me ha dado para continuar con ello hasta obtener un proyecto perfeccionado para su publicación. También le tengo que agradecer la ayuda que me ha prestado de manera totalmente desinteresada para la publicación del mismo. Sin más me despido y espero que os sea de ayuda este documento así como el proyecto en si. Pueden ponerse en contacto conmigo en esta dirección de correo electrónico sin problema alguno: jdyb04jdyb@gmail.com Jdyb - Mayo

4 2.- Introducción En este proyecto se ha tratado de llevar a cabo el diseño de una aplicación web que cumpla con las funcionabilidades de una tienda online completa. La aplicación debe tener una interfaz de administración la cual nos permita una administración completa de los productos (añadir, modificar, borrar y consultar), también es posible la búsqueda de productos. Jdyb - Mayo

5 Para acceder a la zona de administración es necesario estar autentificado, la autentificación se realiza mediante un correo electrónico y una contraseña. También es posible que los usuarios se registren en la aplicación con la ventaja de que no tendrán que introducir los datos completos para realizar la compra. También podrán consultar su historial de compras y por supuesto modificar sus datos. Jdyb - Mayo

6 La parte principal de la aplicación es el listado de productos donde el usuarios puede añadirlos a la cesta de la compra. El usuario podrá consultar el estado de su carrito en todo momento y podrá editar la cantidad de cada producto según desee. Jdyb - Mayo

7 Cuando el usuario quiera dar por terminada su compra tendrá que rellenar el formulario con los datos de la compra en el caso de no estar registrado. En caso contrario lo único que tendrá que hacer es seleccionar la forma de pago. Posteriormente un correo electrónico será enviado al usuario con los detalles de la compra. La aplicación tiene otras funcionabilidades extra a parte de las básicas de una tienda online. Es posible añadir comentarios a los productos siendo un usuario registrado. Jdyb - Mayo

8 Es posible también asignar imágenes a los productos, el sistema está capacitado para enviar s a los usuarios cuando se registran, cuando realizan una compra, y también tienen la opción de recuperar la contraseña en caso de pérdida; el sistema genera una nueva contraseña y es enviada por correo electrónico al usuario. Jdyb - Mayo

9 Cuenta con la opción de usar persistencia contra bases de datos así como persistencia contra ficheros en formato binario de objetos serializados. Como ayuda a los administradores cuenta con un registro de peticiones realizadas al servidor que son guardados en una base de datos o en fichero (según sea el método de persistencia); este registro ayudará a realizar un seguimiento detallado para los administradores. Es posible la visualización de estadísticas de ventas, esta opción estará disponible para aquellos usuarios que sean administradores de la tienda. Jdyb - Mayo

10 3.- Diseño del sistema Herramientas utilizadas Como lenguaje de programación para la aplicación en el servidor se ha usado Java EE 6, el servidor de aplicaciones usado es GlassFish Server 3.1 Como entorno de desarrollo se ha usado NetBeans 7.0. Para la presentación de cara al usuario se han empleado páginas para la generación del código HTML que finalmente será mostrado al usuario mediante el navegador web que será el que renderice dicho código. Gracias a este diseño se podría decir que el trabajo que hemos tenido que dedicar a la aplicación del cliente es insignificante debido a que no hemos tenido que encargarnos nosotros del desarrollo del navegador, únicamente de generar el código que este renderizará. Esta es la principal ventaja de usar este modelo de diseño unido a que se están usando tecnologías estandarizadas. Jdyb - Mayo

11 3.2.- Patrón de diseño MVC Para el desarrollo del sistema se ha usado un patrón de diseño en el cual hay claramente diferenciadas tres partes. Por una parte nos podemos encontrar con los modelos de datos que en nuestro caso serían los objetos java que necesitamos para representar la información de nuestra aplicación, la cual estaría almacenada en una base de datos, en ficheros o en cualquier otro modo de persistencia. Por otra parte tenemos las vistas que serían las páginas que se encargan de la presentación al usuario. Estas páginas estarían formadas por las páginas estáticas HTML y las páginas dinámicas. Por último tendríamos la parte del controlador que sería la encargada de realizar las acciones necesarias para nuestro modelo de negocio. Esta parte realizará unas acciones y de manera general posteriormente decidirá la vista que se desea presentar al usuario, como ya se ha dicho esta parte se encarga de las operaciones necesarias por el modelo de negocio y por lo tanto será esta parte la que reciba las acciones por parte del usuario. Base de datos Acciones del usuario Actualizar modelo Objetos Java Controlador Usuario Java if(conn SELEC WHERE print Servlet Java EE Seleccionar vista Modelos de vista Consultas al modelo HTML Jdyb - Mayo

12 3.3.- Diseño de la persistencia. Patrón DAO A continuación usaremos el patrón de diseño que se ha usado para el mecanismo de persistencia de la aplicación. Este patrón trata de independizar el tipo de persistencia del resto de la aplicación, de esta manera la aplicación no tiene dependencia del tipo de persistencia que se este llevando a cabo. Por poner un ejemplo, podemos estar desarrollando la aplicación con persistencia contra ficheros y posteriormente decidir que lo queremos hacer contra base de datos y no habría que cambiar nada de la lógica de negocio de la aplicación, únicamente habría que implementar los métodos necesarios para persistir contra la base de datos. Explicamos a continuación en que consiste este patrón de diseño. En primer lugar tendríamos una interfaz que indicaría los métodos que son necesarios en la persistencia (los métodos a los que se llamarán después para acceder a la persistencia). Por cada método de persistencia tendríamos una clase que implementa todos y cada uno de los métodos de la interfaz. Para asegurarnos de que no se crea más de una de estas clases durante el desarrollo de la aplicación deberíamos hacer que estas clases sigan un patrón de diseño singleton (explicado posteriormente). Por último tendríamos una factoría que dependiendo de los argumentos, en nuestro caso parámetros del descriptor de despliegue, nos devolvería una instancia de la clase encargada de la persistencia (dependiendo de los argumentos para el tipo de persistencia). Para acceder a la persistencia no tendríamos mas que acceder mediante la interfaz a los métodos y de esta manera el modelo de negocio de la aplicación es totalmente independiente del tipo de persistencia. El patrón de diseño singleton consiste en crear un constructor para la clase que solo permita que haya una única instancia de la clase en la aplicación. Esto se haría haciendo un constructor que compruebe si hay o no una instancia de la clase en la aplicación, si la hay devolvería es misma instancia, en caso contrario se crearía una nueva instancia. La forma de controlar las instancias existentes es hacer que la propia clase contenga en sus atributos una instancia de ella misma. Mostramos a continuación un diagrama de clases en el que se muestran las dependencias de cada una de estas clases. Jdyb - Mayo

13 Modelo de persistencia. Patrón DAO StartListener private persistence: PersistenceInterface public void contextinitialized(servletcontextevent sce) persistencia.persistencefactory public static PersistenceInterface getinstance (String type) public void contextdestroyed(servletcontextevent sce) private boolean startvalidate(servletcontext context) modelo.producto persistencia.persistenceinterface modelo.usuario modelo.comentario public boolean init (String locationuser, String locationproduct); public boolean exit () public boolean adduser (Usuario user) persistencia.persistencefile persistence: PersistenceFile filenameuser: String filenameproduct: String persistencia.persistencebd instance: PersistenceBD pool: DataSource modelo.carrito public boolean addproduct (Producto prod) public boolean deluser(string mail) productos: Map<String, Producto> usuarios: Map<String, Usuario lockproductos: Object namebd: String logger: Logger public boolean delproduct(string codigo) lockusuarios: Object private ArrayList <String> requestincompletecarts (String mail) public Usuario getuser (String mail) public Producto getproduct (String codigo) public boolean updateuser (String mail, Usuario user) public boolean updateproduct (String codigo, Producto prod) public int anyadmin () public Map <String, Producto> getproducts() public Map <String, Usuario> getusers () public Map<String, Producto> searchprod(string campo, String term) public boolean saverequest (String fechahora, String requestedurl, String remoteaddr, String remotehost, String method, String param, String useragent) public boolean savecart (Carrito cart, boolean completado, String date, String formpago) public Carrito requestlastincompletecart (String mail) public boolean savecart (Carrito cart, boolean completado, String date, String formpago) public boolean deleteimcompletecartsclient (String mailclient) public ArrayList <Carrito> requestsalesrecord (String campo, String term) public ArrayList <Producto> getdetailscartrecord (String codigo) public boolean newcomment (Usuario user, String codigoproducto, String codigocomentario, String fechahora, String comentario) public Comentario getcomment (String codcomentario) public boolean deletecomment (String codigocomentario) public boolean updatecomment (String codcomentario, Comentario comentario) public LinkedList <Comentario> getcomentarios (String campo, String valor) Jdyb - Mayo

14 3.4.- Diseño de filtros En este apartado veremos algunos aspectos del diseño de la aplicación que considero de interés aparte de los ya explicados en los apartados anteriores. Hay un filtro que recoge todas las peticiones y se encarga de registrar cada una de las peticiones, en este filtro de setean tanto la respuesta como la petición con la codificación que usa toda la aplicación; de esta manera nos aseguramos de que toda la aplicación este funcionando en la misma codificación para evitar problemas. Ahora bien, esto no nos asegura de que el resto de cosas externas sigan en la misma codificación (UTF- 8), como pueden ser las bases de datos u otros recursos externos que se usen en la aplicación. La autentificación de la aplicación está basada en el uso de filtros. Hay un filtro que nos permite acceder a la zona de usuarios registrados de la aplicación (dependiendo de los atributos de la sesión) y un filtro posterior que verifica que podamos acceder a la zona de administración, zona a la que solo deben acceder los usuarios con suficientes permisos Acceso a los mecanismos de persistencia Respecto al modelo de persistencia que se ha comentado se podría añadir que para acceder a las funciones de la persistencia lo que se realiza es obtener siempre la interfaz que se guardó en el contexto de la aplicación al inicio de la misma con un listener de inicio de contexto Seguridad de la aplicación La aplicación ha sido diseñada prestando mucha atención a los aspectos de seguridad de la misma, no se ha tenido absolutamente ninguna idea preconcebida a la hora del diseño de la misma, se ha partido del pensamiento de que todo ha de ser validado. En primer lugar se ha optado por la opción de eliminar las contraseñas de las bases de datos, la aplicación no contiene ninguna contraseña, en ningún momento son guardadas. Lo que se almacena es una huella de la contraseña mas una pequeña cadena fija para que sea resistente también a los ataques por diccionario a la base de datos en busca de huellas conocidas. Cuando el usuario introduce una contraseña se seguiría se obtendría la huella de la misma y lo que se compara serían las dos huellas. Sin asegurarlo totalmente podría afirmar que la única forma de que un usuario se hiciera con la contraseña de otro sería teniendo un sniffer en la red de la víctima Jdyb - Mayo

15 (puesto que la aplicación no funciona sobre https), otra opción sería intentar robar la sesión de alguna manera, pero así no se conseguiría la contraseña del usuario, sino acceso a su sesión por un periodo limitado de tiempo. Otro aspecto importante en la seguridad son todas las entradas de datos que se reciben del usuario tanto de formularios como de cualquier tipo de petición que tenga que atender el servidor, no se debe dar por supuesto nada. En todos los formularios que recibe la aplicación lo primero que se hace con ellos es verificar que contengan los parámetros que deseamos (dependiendo del formulario concreto), y posteriormente todos los parámetros recibidos son validados con la librería ESAPI mediante expresiones regulares, evitando de esta manera intentos de Cross Site Scripting o de inyección SQL. También son validados todos aquellos campos que deben permitir cualquier texto (como puede ser el caso de los comentarios) en busca de cualquier etiqueta HTML sospechosa y también se contemplan los ataques usando codificaciones diferentes. Posteriormente una vez validados cada uno de los parámetros se analiza cada uno de ellos para verificar que tengan sentido, no se permiten números negativos, no se permite eliminar al último administrador, no se permite subir un archivo que no sea una imagen y como tamaño máximo 8mb. A la hora de construir el sistema se ha construido con una idea final en mente que es procurar en la medida de lo posible o en todos los casos si es posible que la aplicación fallase por el uso incorrecto de los usuarios o el intento de introducción de datos erróneos en formularios o intento de jugar con las URLs de la aplicación. Con esto quiero decir que para cada acción que realiza la aplicación primero se comprueba si es posible realizarla. Por ejemplo, no se puede borrar un administrador si es el único que hay, no se pueden comprar mas unidades de las que tiene un producto, no se puede borrar o editar un producto o usuario que no existe. También se ha procurado que solo se pueda acceder a los Servlets por mediante el verbo http (GET o POST) para el que estén pensados, de intentarse un acceso usando un verbo no permitido sería lanzado un error 404, se puede ver en detalle en los diagramas de navegación. El número de intentos de inicio de sesión se ha restringido a 10 intentos, una vez sobrepasado ese límite no se podría volver a iniciar sesión durante 10 minutos. Jdyb - Mayo

16 4.- Modelos de datos usados En este apartado se explicarán los modelos de datos que han sido usados para representar todos los datos con los que trabaja la aplicación Modelo de datos de Producto Con esta clase se pretender representar un producto de la tienda con todos los atributos que contiene, estos atributos serán los requeridos por el enunciado. Código (Creado de manera automática usando UUIDs) Nombre Precio Stock Descripción corta Detalles Se presenta a continuación un diagrama UML representando la clase. Producto Producto codigo: String nombre: String precio: double stock: int desc: String detalles:string public Producto () public Producto(String codigo, String nombre, double precio, int stock) public Producto(String codigo, String nombre, double precio, int stock, String desc, String detalles) public String getdesc() public String getdetalles() public String getnombre() public double getprecio() public int getstock() public String getcodigo() public String getdisponibilidad () Jdyb - Mayo

17 Como se puede observar en el diagrama UML no hay ningún método en esta clase que permita modificar el producto por lo que se puede decir que las instancias de esta clase serán inmutables, una vez creados los objetos no será posible modificar los mismos. Se ha hecho de esta manera para evitar problemas de concurrencia. Si los objetos no son inmutables sería posible por ejemplo que un usuario que esta comprando cambiara las unidades de un producto mientras que el administrador cambie las unidades del mismo producto Modelo de datos para el usuario Con esta clase se pretende representar un usuario dentro de la tienda online. Cada objeto de la clase tendrá los siguientes siguientes atributos. Nombre Dirección (identificador único) Contraseña (MD5 de la contraseña) Permisos ( a Administrador, c Cliente normal) A continuación de puede observar un diagrama UML representando la clase. Usuario Usuario nombre: String dir: String mail: String pass: String permisos: char public Usuario () public Usuario(String nombre, String dir, String mail, String pass, char permisos) public String getdir() public String getmail() public String getnombre() public String getpass() public char getpermisos() public String getprintablepermissions () Jdyb - Mayo

18 4.3.- Modelo de datos para el la cesta de la compra Con esta clase se pretende representar la cesta de la compra de un usuario. El carrito de la compra tiene los siguientes atributos. Código del carrito del usuario Mapa de productos que contiene los productos añadidos al carro Precio del carro completo Fecha de la compra Hora de la compra Forma de pago de la compra Carrito Carrito codigo: String user: String articulos: Map <String, Integer> precio: double fecha: String hora: String formpago: String public Map <String, Integer> getarticulos () public int getlenght () public double getprecio () public String getcodigo() public void setprecio (double price public String getfecha() public String getformapago () public void addproduct (String newprod, int cantidad, double prodprice) public Carrito () public Carrito(String codigo, String user) public Carrito(String codigo, String user, double precio) public Carrito(String codigo, String user, double precio, String fecha, String hora, String formapago) public boolean editcant (String prod, int cantidad, double prodprice) public void delproduct (String prod) public String getuser() public void setarticulos (Map<String, Integer> articulos) public String gethora() public void setuser(string user) public void removeprod (String prod, double prodprice) Jdyb - Mayo

19 4.4.- Modelo de datos para los comentarios Con esta clase se pretende representar un comentario añadido por un usuario a un producto del catálogo de la tienda. Un comentario se representa con los siguientes atributos. Código del comentario Fecha Hora Código del producto del usuario Nombre del usuario Texto del comentario Comentario Comentario codigocomentario: String fecha: String hora: String codigoproducto: String String nombre: String comentario: String public Comentario(String codigocomentario, String fecha, String hora, String codigoproducto, String , String nombre, String comentario) public String get () public String getcodigocomentario() public String getcodigoproducto() public String getcomentario () public String getfecha() public String gethora() public String getnombre() public String getfechahora () Jdyb - Mayo

20 5.- Configuración de la aplicación En este capítulo se van a describir diferentes aspectos de configuración de la aplicación necesarios para poder desplegar la aplicación correctamente Configuración de persistencia en modo fichero Es posible que la aplicación funcione con persistencia contra ficheros. Para que funcione correctamente es necesario configurar una serie de parámetros en el descriptor de despliegue de la aplicación. Lo primero que tenemos que hacer es indicar que la persistencia de la aplicación va a funcionar contra ficheros. Para ello tenemos que configurar el parámetro de contexto persistencemethod. El valor que debe tener este parámetro para que funcione con ficheros es file. Posteriormente lo que tendremos que hacer es configurar la ruta de los ficheros, si únicamente pone el nombre del fichero se guardaran en el directorio del dominio del servidor de aplicaciones. Los archivos van a ser cargados usando directorios del sistema, no se van a emplear métodos de contexto o del classpath para cargarlos. La ruta del fichero que contiene los datos de productos y usuarios viene dado por el parámetro de contexto archivodatos. Es un fichero de tipo binario. La ruta del fichero que contiene el historial de carritos viene dada por el parámetro de contexto archivohistoriales. Es un fichero de tipo binario La ruta del fichero que contiene carritos sin comprar que son guardados para ser recuperados al inicio de la sesión de los usuarios viene dada por el parámetro de contexto archivorecuperacion. Es un fichero de tipo binario. Jdyb - Mayo

21 La ruta del fichero de registro de acciones viene dada por el parámetro de contexto archivolog. Es un fichero de texto plano. Jdyb - Mayo

22 5.2.- Configuración de persistencia en modo de bases de datos La aplicación también está preparada para que la persistencia funcione contra bases de datos, para ello se emplea un pool de conexiones que es necesario configurar en el servidor de aplicaciones, y en el descriptor de despliegue. La aplicación se ha desarrollado con una base de datos MySQL, para preparar la base de datos para la aplicación se incluye junto con este documento un export de la base de datos completa. A continuación se muestran los datos que son necesarios para configurar el pool de conexiones Nombre del recurso: el que se desee. JNDI: jdbc/onlineshop (el nombre que será usado en el descriptor de despliegue) Motor de bases de datos: MySQL Nivel de aislamiento de las transacciones: READ- COMMITED Puerto: 3306 (puerto por defecto de mysql) Nombre de la base de datos URL: jdbc:mysql://hostbasedatos Nombre del servidor Usuario Contraseña Para que el pool de conexiones funcione es necesario incluir el conector de la base de datos en los directorios del servidor de aplicaciones. El conector para MySQL lo puede descargar desde la página web oficial. Una vez descargado debe incluir el archivo jar del conector en el directorio del servidor de aplicaciones. En el caso de GlassFish será el siguiente. glassfish- 3.1/glassfish/lib Una vez se ha configurado el servidor de aplicaciones hay que pasar a configurar la aplicación. Jdyb - Mayo

23 En primer lugar es necesario configurar el modo de persistencia en el descriptor de despliegue. En segundo lugar hemos de configurar el nombre del recurso JNDI y posteriormente el nombre de la tabla. Para ello se usan parámetros del contexto que fueron usados para la persistencia en modo de fichero. También es necesario configurar el recurso en el descriptor de despliegue. Por último se ha de configurar el recurso en el descriptor de despliegue específico del servidor de aplicaciones. En el caso de GlassFish se haría como se puede ver aquí. A continuación se muestran las sentencias SQL necesarias para crear las tablas necesarias de la base de datos. Jdyb - Mayo

24 Jdyb - Mayo

25 5.3.- Configuraciones misceláneas sobre la aplicación Si la aplicación no encuentra un usuario administrador automáticamente lo creará partiendo de una serie de parámetros del descriptor de despliegue. Es necesario tener en cuenta que debido a que existen validaciones de datos en la aplicación los datos introducidos tendrán que ser datos válidos. Es posible configurar la caducidad de la sesión de usuario en minutos, esto indica el tiempo en el que si la sesión está inactiva se cerrará de manera automática. Sobre el contexto de la aplicación es necesario indicar que está preparada para funcionar sin contexto directamente sobre la raíz del servidor de aplicaciones debido a que todas las rutas usadas en la aplicación se dan a partir de la raíz del servidor. Si se configurara un contexto habría que configurar de nuevo todas las rutas de la aplicación. Este parámetro de configuración lo encontramos en el descriptor de despliegue propio del servidor de aplicaciones. Mostramos como se haría para GlassFish. También es necesario que la carpeta setup de la aplicación este añadida al classpath de ejecución de la máquina virtual. En esta carpeta se encuentran ficheros de configuración de las librerías de validación y las plantillas de los s que son enviados. Jdyb - Mayo

26 5.4.- Configuración del servidor SMTP para el envío de s La aplicación permite el envío de s a los usuarios cuando son registrados con sus datos de registro, también cuando una compra es realizada detallándose en el mismo los detalles de la compra y por último también admite la posibilidad de recuperación de la contraseña de los usuarios en caso de olvido. Para el envío de los s es necesario configurar un servidor SMTP y será configurado desde el descriptor de despliegue de la aplicación mediante los parámetros de contexto. Los parámetros con los que viene configurado son plenamente funcionales. hostmail: Host del servidor SMTP TSLMail: Si el servidor permite o no cifrado TSL mailport: Puerto del servidor SMTP mailuser: Usuario con el que es necesario iniciar sesión para enviar los correos Jdyb - Mayo

27 authmail: Si es necesaria o no la autentificación para el envío de mensajes mailfrom: Dirección de del remitente que aparecerá en los correos enviados mailpass: Contraseña del servidor SMTP A continuación se muestra un ejemplo de configuración en el descriptor de despliegue de la aplicación. Jdyb - Mayo

28 5.5.- Configuración de las plantillas para el envío de s Existen plantillas personalizables para el envío de s. Las podemos encontrar en la carpeta setup que como hemos dicho debe de estar añadida al classpath de la máquina virtual de java. En primer lugar encontramos la plantilla con nombre plantillacompra.html. Esta plantilla será usada para el envío de s detallando los detalles de la compra. Usted decide la información que desea incluir en la plantilla con las siguientes claves, donde usted ponga los siguiente códigos será donde aparezca en el la información correspondiente. &LISTA: Aquí aparecerá una tabla detallando la lista de productos siguiendo los estilos css.headertable y.contenttable que indican el estilo de la cabecera y el contenido respectivamente &TOTAL: Aquí aparecerá el total de la compra en euros y con dos decimales. &NAME: Nombre del cliente & del cliente &DIR: Dirección del cliente &FORMPAGO: Forma de pago escogida por el cliente La plantilla de envío de recuperación de contraseña está bajo el nombre plantillarecuperarpass.html. Se detallan a continuación los códigos para la inclusión de datos. &NAME: Nombre del cliente & del cliente &PASS: Nueva contraseña para el cliente La plantilla de registro para los usuarios esta bajo el nombre plantillaregistro.html. Se detallan a continuación los códigos para la inclusión de datos. &NAME: Nombre del cliente elegido para el registro Jdyb - Mayo

29 & del registro &DIR: Dirección del cliente para el registro Librerías necesarias En este capítulo vamos a detallar cuales son las librerías que han sido usadas en el desarrollo de la aplicación. Podemos encontrar las librerías necesarias en la carpeta lib. ESAPI 2.0GA Librería usada para la validación de entradas de usuario está situado dentro de la carpeta lib y necesita las librerías que están incluidas en la carpeta esapi- required. Los ficheros de configuración necesarios para esta librería se encuentran en la carpeta setup que como hemos indicado hay que añadirla al classpath. ESAPI.properties: Fichero principal de configuración de ESAPI validation.properties: Fichero de configuración para las expresiones usadas en la validación antisamy- slashdot xml: Fichero de validación de HTML para HTML que pueda introducir el usuario JFreeChart es la librería que se ha usado para generar las gráficas de estadísticas, situada en la carpeta lib y requiere la librería Jcommon también situada en la carpeta lib. Jdyb - Mayo

30 Jdyb - Mayo

31 6.- Funcionamiento en detalle del sistema En este apartado se va a detallar el flujo de navegación de cada una de las operaciones que se pueden realizar y de esta manera comprender mejor su funcionamiento Estructura de la aplicación En el presente apartado vamos a ver como se ha organizado la aplicación en directorios según las funciones de cada Servlet, clase java o vista. Mostramos en primer lugar la organización de Servlets y clases en los diferentes paquetes. Mostramos a continuación la organización de vistas de la aplicación. Jdyb - Mayo

32 En primer lugar podemos observar como tenemos un paquete control.admin, al igual que en las vistas también lo hay, dentro de la carpeta admin podemos encontrar también una carpeta administration. Dentro del paquete control.admin de archivos java también se encuentra un directorio que no se ve también llamado administration, Jdyb - Mayo

33 podemos observar que existe este directorio en el descriptor de despliegue en la configuración de los Servlets. La función que cumple el directorio admin es almacenar en el mismo las acciones de administración, pero sólo aquellas que se puedan llevar a cabo siendo usuario registrado pero sin permisos de administrador. La entrada a este directorio se comprueba con el filtro AdminFilter definido en el descriptor de despliegue de la aplicación. En el directorio administration es donde se encuentran todas las acciones que se pueden llevar a cabo siendo administrador, que son todas aquellas que se refieren a la administración de la tienda. La entrada en esta zona es comprobada por el filtro AdministrationFilter, este filtro solo comprueba si el usuario es administrador o no lo es, no es necesario que compruebe la autentificación del usuario debido a que ya ha sido comprobada por el filtro AdminFilter el cual se encuentra antes que este. También podemos observar el paquete modelo, en el cual se encuentran los beans utilizados en la aplicación. Dentro del mismo encontramos las clases que representan un carrito de la compra, un comentario, un usuario o un producto. Dentro de paquete control encontramos diferentes Servlets y clases usados para realizar diferentes funciones de la aplicación, será explicada cada uno de ellos en detalle posteriormente. Podemos observar también el paquete persistencia en el cual se encuentran las clases necesarias que se describieron anteriormente, todas ellas juntas forman el patrón DAO de la aplicación. Por último podemos observar el paquete control.productos, todo lo que hay dentro de este paquete es accesible mediante la ruta /shop que si observamos hay una carpeta que se llama así en las vistas de la aplicación. Todo lo que se encuentra dentro de este directorio hace las funciones necesarias para la compra y todas aquellas acciones a realizar con los productos, eso sí, únicamente aquellas acciones públicas. Pasemos a ver ahora la estructura organizativa de las vistas de la aplicación. En primer lugar comentar que todas las vistas son páginas dinámicas, no hay contenido estático html. Como ya hemos visto anteriormente teníamos las carpetas admin y administration, que ya se ha comentado que tipo de funciones agrupaban. Posteriormente observamos la carpeta css, en la cual podemos encontrar la hoja de estilos de la aplicación, todas las vistas de la aplicación usan esta hoja de estilos. También podemos encontrar dentro de esta carpeta la hoja de estilos que aplicada sobre los formularios a la hora de la validación mediante JavaScript. Jdyb - Mayo

34 Observamos una carpeta llamada images, dentro de esta carpeta se guardarán todas las imágenes que use la aplicación, dentro de la misma habrá varias carpetas. La carpeta icons contiene los iconos que se usan en la aplicación, como por ejemplo puede ser el carrito de la compra. Posteriormente vemos la carpeta products que contiene las imágenes de los productos, cada una de ellas tiene como nombre el código del producto al que pertenece. Observamos la carpeta stats la cual contiene todas las imágenes referentes a las estadísticas gráficas de la aplicación. Las estadísticas gráficas serán generadas y almacenadas en esta carpeta y serán posteriormente mostradas al usuario. Por último la carpeta template, la cual contiene todas las imágenes utilizadas por la plantilla de la aplicación. Posteriormente vemos en la raíz de la aplicación el home, la página de login y la página de acerca de. Después podemos encontrar la carpeta scripts, dentro de la cual podemos encontrar todos los documentos javascript usados en la aplicación. Dentro de esta carpeta observamos el documento jquery js, que es la librería jquery necesaria para usar otros plugins que se han usado que se verán a continuación. El documento scripts.js incluye una serie de funciones creadas para no tener que escribirlas directamente en las páginas jsp sino solo tener que llamar a estas funciones. Por ejemplo, podemos encontrar dentro de este documento la función necesaria para cargar el editor de textos tiny- mce. Posteriormente encontramos la carpeta tiny_mce en la que se encuentran todos los elementos del plugin tiny- mce. Finalmente observamos el documento vanadium.js que es el la librería usada para las validaciones de javascript. Este documento ha sido modificado para dar los mensajes en español y también se han modificado algunas de las expresiones regulares de validación y se han añadido otras. Observamos la carpeta shop que contiene las vistas de las acciones a realizar referentes a las acciones con los productos y con la compra, siempre y cuando sean públicas. Posteriormente tenemos la carpeta WEB- INF, en la cual se encuentran aquellas páginas a las que no deseamos que el usuario llegue directamente, tiene varias Jdyb - Mayo

35 carpetas dentro y en su raíz el descriptor de despliegue y el fichero de configuración específico del servidor de aplicaciones usado (GlassFish 3.1). Encontramos en primer lugar la carpeta admin que contiene la página de logout, a la cual tiene lógica que no se llegue sin realizar esa acción en concreto, también tiene la página de pre- visualización de producto que es usada al editar y añadir productos y tiene lógica que solo se llegue a esta página a través de dichas acciones (la función de previsualización ha sido eliminada en la última versión). Encontramos la carpeta include que contiene páginas jsp que van a ser incluidas en las vistas de la aplicación, a estas páginas no se debe llegar, solo deben ser incluidas en el cuerpo de otras páginas jsp. Dentro de esta carpeta podemos encontrar el header de la aplicación que contiene el menú superior y la barra superior, también encontramos el footer o pie de página de la misma, observamos también una página llamada resultados que es la encargada de mostrar los resultados de las acciones realizadas y esta es incluida en todas las páginas jsp que esperan recibir mensajes de los resultados de las acciones. Encontramos también en este directorio el menú de la aplicación tanto para la sección de administración como para el resto de las secciones (menu, menuadministracion). Por último encontramos el módulo de comentarios de la aplicación que será el que es incluido en la página de visualización de producto para que muestre los comentarios de los productos. Finalmente encontramos un directorio que contiene las páginas de error (paginaserror) de la aplicación, a las cuales no se debe llegar salvo que haya ocurrido el error pertinente. Jdyb - Mayo

36 6.2.- Diagramas de navegación de filtros En este apartado mostraremos los diagramas de navegación referentes a los filtros para evitar mostrarlos en los diagramas de navegación de todas las acciones por claridad. Todas las peticiones Java LogFilter.java Destino Guarda registro de petición V Peticiones dirigidas a /admin/* Java Java Autentificado LogFilter.java AdminFilter.java Sin autentificar Destino restricted.jsp Jdyb - Mayo

37 Peticiones dirigidas a /admin/administration/* Java Java Sin autentificar LogFilter.java AdminFilter.java restricted.jsp Autentificado Java Administrador Destino AdministrationFilter.java Usuario registrado /admin/index.jsp Jdyb - Mayo

38 6.3.- Diagramas de navegación de listeners En este apartado detallamos los diagramas de navegación para los listeners de la aplicación. Listener de inicio de contexto Despliegue de la aplicación Persistencia cargada if(conn SELEC WHERE print Java Error inicializando persistencia /index.jsp StartListener.java RuntimeException Listener de sesión Sesión caducada o cerrada Si no es usuario registrado; o si lo es pero no tiene carro. Continua el flujo normal if(conn SELEC WHERE print SaveSession Listener.java Si es usuario autentificado y tiene carro sin comprar Continua el flujo normal de navegación Destino Guarda carrito que no se ha confirmado Jdyb - Mayo

39 6.4.- Flujo de navegación de las operaciones públicas En este apartado se verá el flujo de navegación de las operaciones que se pueden realizar en la tienda de manera pública. En estos diagramas podremos ver cuadros en los que pone GET y POST, esto indica las acciones que se realizarán en caso de acceder a los servlets mediante un verbo u otro de los métodos http. Para este primer diagrama vamos a mostrar como se sigue el diagrama con capturas de pantalla para que se tome como ejemplo para entender el resto de los diagramas. Añadir producto al carrito Listado de productos Java <script var a= var xl if(xls /shop/products.jsp AddCarritoServlet Añade el producto al carro si corresponde Caso de error añade un mensaje a la petición Si el error es formulario incorrecto o petición POST Error 404 Jdyb - Mayo

40 Actualizar unidades de un producto en el carrito Listado de productos en el carrito Java <script var a= var xl if(xls Si la sesión no contiene carrito EditAmount Servlet Formulario incorrecto /shop/ products.jsp /shop/cart.jsp Error 404 Actualiza el carro si las comprobaciones son positivas Si hay error en las comprobaciones se añade mensaje Para borrar un producto de la cesta se seguiría el mismo mecanismo con la salvedad de que la cantidad que se pediría son cero unidades. Jdyb - Mayo

41 Borrar el carrito de la compra (vaciarlo) Java Listado de productos en el carrito <script var a= var xl if(xls DeleteCart Servlet /shop/cart.jsp Validar carrito de la compra (paso previo a la compra) Listado de productos en el carrito GET Java <script var a= var xl if(xls Si se han hecho cambios en el carrito se avisa UpdateCart Servlet /shop/cart.jsp Si no hay carrito en la sesión Si no es la operación de venta definitiva Listado de productos Formulario de venta /shop/products.jsp /shop/buycart.jsp POST Error 404 Jdyb - Mayo

42 Realizar la compra Formulario de venta Java <script var a= var xl if(xls Si se han hecho cambios en el carrito se avisa /shop/buycart.jsp POST UpdateCart Servlet Listado de productos Si no hay carrito en la sesión Java <script var a= var xl if(xls BuyServlet Error 404 GET /shop/products.jsp POST Fallos o cambios en el carrito Compra exitosa Compra realizada Registro de la compra Enviar /shop/buyinformation.jsp Es importante destacar de este diagrama el paso previo antes de la compra por el Servlet UpdateCartServlet, es posible que el que lo vea se pregunte porque pasa antes por aquí que por el Servlet que realmente realiza la compra. Se ha diseñado así por cuestiones de rendimiento. El Servlet que realiza la compra comprueba si las unidades son correctas o no y edita el catálogo, pero estas operaciones las realiza de manera sincronizada y pidiendo locks, por lo que el rendimiento de la aplicación disminuiría significativamente en el caso de que hubiera muchos hilos concurrentes ejecutando el Servlet de compra. Por ello se ha implementado el primer Servlet, en el que se realizan esas operaciones (sin editar productos) pero no son sincronizadas y de esta manera Jdyb - Mayo

43 evitamos que todas las peticiones lleguen al servlet que realiza la compra. Se podría decir que de esta manera reducimos las peticiones que llegan al servlet de compra y las que llegan al mismo tienen un porcentaje de acierto mayor a la hora de completar la compra con éxito. También es importante este paso previo antes de la compra porque ese servlet también realiza una actualización del precio del carrito por si algún producto cambió el precio en el periodo de tiempo en el que ha estado ese producto en el carrito. De esta manera aseguramos que el precio que se paga por el carrtito es el actual. Busqueda de productos Java GET Busqueda <script var a= var xl if(xls SearchProduct Servlet POST Error 404 /shop/products.jsp Correcto Sin parámetros de vuelta Buscar productos Jdyb - Mayo

44 Registro de usuarios Registro GET Error 404 /login.jsp POST Ante errores hay mensajes Registro correcto Nuevo usuario Enviar registro Inicio de sesión Java GET Inicio de sesión Login <script var a= var xl if(xls AuthServlet POST Error 404 Autentificación correcta Errores en la autentificación Página a la que se intentó acceder y dio error Inicio de sesión manual Inicio de sesión después de un error Inicio /index.jsp Jdyb - Mayo

45 Recuperación de contraseña Inicio de sesión Java <script var a= var xl if(xls GET /login.jsp PassRecover Servlet Proceso correcto Error 404 POST Error en el proceso Actualizar contraseña Envio para recuperar la contraseña Jdyb - Mayo

46 Juan Díez- Yanguas Barber Programación con Java EE Tienda Online Flujo de navegación para operaciones de usuario registrado En este apartado se va a detallar el flujo de navegación para las operaciones que pueden realizar los usuarios registrados (no administradores). Cambio de contraseña Cambio de contraseña Java <script var a= var xl if(xls GET Error 404 ChangePass Servlet POST /admin/ preferences.jsp Error en el proceso Proceso completado /WEB-INF/ admin/ logout.jsp Java <script var a= var xl if(xls No se encuentra el usuario de la sesión LogOutServlet Actualizar datos Jdyb - Mayo

47 Cambiar los datos personales GET Cambio de datos personales Java <script var a= var xl if(xls /admin/preferences.jsp EditUserServlet POST Error 404 Error en el proceso Proceso completado Actualizar datos Añadir comentario al producto Java GET Añadir comentario /shop/ viewprod.jsp? prod= Error en el proceso <script var a= var xl if(xls AddComment Servlet POST Proceso completado Error 404 Guardar datos Jdyb - Mayo

48 Cerrar sesión Java Cerrar sesión <script var a= var xl if(xls LogOutServlet /logout Sesión no iniciada La sesión se cerro por un error Cierre normal Login /index.jsp /login.jsp Login /WEB-INF/ admin/ logout.jsp Jdyb - Mayo

49 Juan Díez- Yanguas Barber Programación con Java EE Tienda Online Flujo de navegación de las operaciones del administrador En este apartado veremos en detalle como es el flujo de las operaciones que puede realizar un usuario de la tienda con permisos de administrador. Añadir producto al catálogo Java Añadir al catálogo <script var a= var xl if(xls AddProduct Servlet GET Error 404 /admin/ administration/ addproduct.jsp POST Error guardando Exito guardando Si hay imagen Administración de productos Guarda producto Image /admin/administration/ products_administration.jsp Jdyb - Mayo

50 Editar producto del catálogo Editar producto Java <script var a= var xl if(xls EditProduct Servlet GET /admin/ administration/ modifyprod.jsp POST Error 404 Administración de productos Error guardando Exito guardando /admin/administration/ products_administration.jsp Guarda producto Si cambia la imagen Image Si se cambia la imagen o si no se conserva la anterior Borrar imagen Jdyb - Mayo

51 Editar usuario GET Editar usuario Java <script var a= var xl if(xls EditUserComplete Servlet POST Error 404 /admin/administration/ edituser.jsp?user= Errores Operación completada Administración de usuarios Actualizar usuario /admin/administration/ user_administration.jsp Borrar usuario Lista de usuarios Java <script var a= var xl if(xls Error en peticion /admin/administration/ user_administration.jsp DeleteUser Servlet Error 404 Borrado correcto Error en el proceso Borrar usuario Jdyb - Mayo

52 Listado productos Borrar producto Borrar producto /admin/administration/ products_administration.jsp /admin/administration/ delprod.jsp?prod= Cancelar Confirmar Java <script var a= var xl if(xls POST Error 404 GET DeleteProduct Servlet Error Exito Si el producto tiene imagen Borrar imagen Borrar producto Jdyb - Mayo

53 Editar comentario Producto Editar comentario /shop/viewprod.jsp? prod= /admin/administration/ editcomment?cod= Error 404 Parámetros correctos Parámetros incorrectos Error validación Java <script var a= var xl if(xls EditComment Servlet Correcto Errores Actualizar comentario Jdyb - Mayo

54 Borrar comentario Producto Java <script var a= var xl if(xls DeleteComment Servlet Error 404 /shop/viewprod.jsp? prod= Error parámetros o POST Borrado correcto Borrado fallido Jdyb - Mayo

55 6.7.- Sobre el JavaScript que se ha usado Todo el JavaScript usado en el sistema usan la librería JQuery, cuya principal función consiste en facilitar el acceso al documento HTML, facilitar el manejo de eventos así como en el uso de Ajax. En primer lugar podemos destacar la librería VanadiumJS que nos ayuda a la validación de formularios mediante JavaScript. Esta librería es capaz de validar campos de los formularios simplemente poniendo la clave correspondiente en el atributo class del campo del formulario y nos da el mensaje de error siguiendo la hoja de estilos que está dentro de la carpeta css. Mostremos un ejemplo para el formulario de login. Mostramos a continuación la web de la librería usada, aunque el documento de la librería que se usa en esta aplicación ha sido modificado para dar los mensajes en español y también se han modificado algunas de las expresiones regulares y se han añadido otras expresiones regulares como por ejemplo para validar las direcciones. Otra de las librerías usadas es Tiny- MCE el cual sirve para que los cuadros de texto de los textarea sean cuadros de texto WYSIWYG. Para ello hay que inicializar las páginas que contengan los textarea con una función que especifica las opciones de plugin. Esta función la podemos ver en el documento scripts.js. Jdyb - Mayo

56 Dejo a continuación la web del plugin en donde se puede obtener más información acerca de las opciones. Algo que hay que tener muy en cuenta a la hora de usar este plugin es que se ha dejado muy corto de opciones debido a que se valida el html de entrada en el servidor por cuestiones de seguridad, por lo que hay ciertas etiquetas de html o css que no están permitidas, por ello el fichero XML de configuración de antisamy está adaptado especialmente a este plugin. Otro aspecto muy importante a tener en cuenta es que la combinación de estos dos plugins puede tener problemas, a continuación explico las causas. El cuadro de texto WYSIWYG que se genera no es el mismo textarea que hay en nuestro html, se podría decir que es uno virtual, por lo que nosotros escribimos en el virtual, por lo tanto nuestro textarea está vacío y por esta causa la validación por la librería Vanadium fallaría. Por ello lo que hay que hacer es volcar el contenido del cuadro de texto WYSIWYG en el textarea real de nuestro html. Para ello hemos de usar eventos, yo para solucionarlo que he hecho es que se vuelque el contenido con cualquier cambio que se produzca en el campo de texto. Esto lo podemos configurar en la función de inicialización del cuadro WYSIWYG. El código consiste simplemente en que se asigna una función al evento y esa función lo que realiza es el volcado del contenido. Jdyb - Mayo