Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Tarragona
2014
Resumen
2
Resumen
Resumen
Hoy en día, muchos agentes comerciales o distribuidores de productos de marcas
siguen estancados en los métodos tradicionales para realizar sus tareas. Uno de estos
métodos es la recogida de pedidos mediante el teléfono móvil o directamente en persona;
otro método sería realizar la típica factura a mano o incluso con programas de hojas de
cálculo. Con esta aplicación se modernizará el ámbito de trabajo de estos agentes.
Por una parte, los clientes podrán encargar productos mediante cualquier dispositivo,
simplemente a través de su navegador web. Además, esto significa que tendrán toda la
información de los productos, facturas, datos, etc., en cualquier momento a su disposición.
Por otra parte, el agente comercial tendrá un control total de sus usuarios, productos o
facturas, gestionando así todo de una manera más fácil y rápida. No solo la gestión es
importante, ya que si podemos ahorrar tiempo a estos trabajadores generando las facturas
automáticamente, a partir de un pedido, aumentaría su producción y se reducirían los
costes de tiempo o de dinero, en el caso de que tenga a alguien encargado de la gestión.
Resum
Avui en dia, molts agents comercials o distribuidors de productes de marques
segueixen estancats en els mètodes tradicionals per realitzar les seves tasques. Un d'aquests
mètodes es la recollida de comandes mitjançant el telèfon mòvil o directament en persona;
un altre mètode seria realitzar la factura típica a mà o inclòs amb programes de fulls de
càlcul. Amb aquesta aplicació es modernitzarà l'àmbit de treball d'aquests agents.
D'una banda, els clients podran encarregar productes mitjançant qualsevol dispositiu,
simplement a traves del seu navegador. A més, això significa que tindran tota l'informació
dels productes, factures, dades, etc., en qualsevol moment a la seva disposició. D'altra
banda, l'agent comercial tindrà control total dels seus usuaris, productes o factures,
gestionant així tot d'una manera més fàcil i ràpida. No només la gestió es important, ja que
si podem estalviar temps a aquests treballadors generant factures automaticament, a partir
d'una comanda, augmentaria la seva producció i es reduirían costos de temps o de diners,
en el cas que tingui a algú encarregat de la gestió.
Abstract
Nowadays, many commercial agents or distributors of designer products remain
being blocked in traditional methods to do their jobs. One of these methods is the order
collection by mobile phone or directly in person; another method is to generate the typical
receipt by hand or even with spreadsheet programs. With this application the work setting
of these agents will be modernized.
On the one hand, costumers will be able to order products by any device, simply
through their web browser. Furthermore, this means that they will have all the information
about the products, receipts, data, etc., at any time at their disposal. On the other hand, the
commercial agent will have a total control of his users, products or receipts, managing
everything in the easiest and fastest way. Not only it is the management important, since if
we can save time to these workers by generating the receipts automatically, the production
will be increased and time and money-cost will be reduced , in the event that someone is in
charge of the management.
3
Índice
Contenido
1 Introducción ....................................................................................................... 7
1.1 Las aplicaciones web ................................................................................... 7
1.1.1 Ventajas .................................................................................................... 7
1.2 El patrón MVC............................................................................................. 8
1.3 La evolución del framework Struts .............................................................. 8
4 Diseño ............................................................................................................... 17
4.1 Estructura de la aplicación ......................................................................... 17
4.1.1 MVC, la base del proyecto ..................................................................... 17
4.1.2 Framework Struts 2 ................................................................................ 18
4.2 Herramientas para el desarrollo del entorno web ...................................... 18
4.2.2 Entorno de programación ...................................................................... 19
4.3 Elección del servidor ................................................................................. 19
4.4 Base de datos ............................................................................................. 20
4.4.1 Definición de los datos ........................................................................... 20
4.4.2 Esquema de la base de datos ................................................................. 20
4.5 Interfaz gráfica ........................................................................................... 21
4
Índice
5 Desarrollo ......................................................................................................... 30
5.1 Implementación del modelo....................................................................... 30
5.1.1 Persistencia ............................................................................................ 30
5.1.2 JDBC ...................................................................................................... 30
5.1.3 JavaBeans (DTO) ................................................................................... 33
5.1.4 DAO........................................................................................................ 34
5.1.5 DAO Factory .......................................................................................... 35
5.1.6 Tuplas ..................................................................................................... 36
5.2 Implementación del controlador ................................................................ 38
5.2.1 FilterDispatcher y configuración web ................................................... 38
5.2.2 Struts.xml y resultados ........................................................................... 38
5.2.3 Variables de sesión y de la vista ............................................................ 39
5.2.4 Interceptores, seguridad básica ............................................................. 40
5.2.5 Validaciones en campos de entrada de texto ......................................... 42
5.2.6 Mensaje de acciones............................................................................... 43
5.3 Implementación de la vista ........................................................................ 44
5.3.1 Páginas JSP............................................................................................ 44
5.3.2 Struts 2 Tags ........................................................................................... 44
5.3.3 JQuery Tags de Struts 2 ......................................................................... 46
5.3.4 Tiles ........................................................................................................ 47
5.3.5 Interfaz general ...................................................................................... 48
5.3.6 Scripts ..................................................................................................... 50
5.4 I18n ............................................................................................................ 51
5.4.1 Acceder a las variables desde el JSP ..................................................... 51
5
Índice
6 Evaluación ........................................................................................................ 57
6.1 Funcionamiento del modelo....................................................................... 57
6.2 Funcionamiento del controlador ................................................................ 58
6.3 Funcionamiento de la vista ........................................................................ 59
6.4 Fase de pruebas con diferentes usuarios .................................................... 60
6.4.1 Resultado final........................................................................................ 60
7 Conclusiones .................................................................................................... 63
7.1 Cumplimiento de los objetivos .................................................................. 63
7.1.1 Objetivos principales.............................................................................. 63
7.1.2 Objetivos de aprendizaje ........................................................................ 63
9 Anexos .............................................................................................................. 67
9.1 Manual de instalación y configuración ...................................................... 67
9.2 Manual de usuario ...................................................................................... 69
9.2.1 Administrador......................................................................................... 69
9.2.2 Cliente .................................................................................................... 72
6
Capítulo 1: Introducción
1 Introducción
En esta primera parte se explicará la tecnología y los conceptos claves que se han
utilizado para realizar esta aplicación web. Primero se hará una pequeña introducción del
concepto de aplicación web, y como ésta se puede estructurar con el patrón MVC.
También se hará un repaso a toda la evolución del framewok Struts, una pieza clave
para este proyecto.
1.1.1 Ventajas
7
Capítulo 1: Introducción
8
Capítulo 1: Introducción
Esta solución fue creada alrededor del año 2000 en forma de framework por Craig R.
MCclanahan's para agilizar los desarrollos Java EE. Meses más tarde fue donada a la
fundación Apache, la cual fue lanzada un año más tarde con el nombre de Struts 1.0.
Al mismo tiempo que este primer framework, otro equipo de desarrolladores crearon
otro con el nombre de WebWork. Éste nunca llegaría a tener tanta popularidad como Struts
1.0 pero incorporaba nuevas características que llamaban mucho la atención como son la
validación de formularios o la ejecución sin necesidad de utilizar ningún navegador.
A finales de 2005, WebWork y Struts 1.0 se fusionaron para formar un único
framework, llamado a priori Struts TI (Titanium) y que poco después pasó a llamarse
Struts 2.0 (el cual es utilizado en este proyecto). Esta fusión pretendía agrupar las ventajas
de los dos frameworks. Sin embargo Struts 2.0 no está basado en Struts 1.0, ya que el
primero tiene un diseño completamente nuevo mayormente basado en WebWork 2.2.
Con lo cual aquellos desarrolladores que sabían todos los comandos y
funcionalidades de la primera versión de Struts tendrán que aprender desde cero todos los
nuevos métodos de Struts 2.0.
9
Capítulo 2: Objetivos del proyecto
10
Capítulo 2: Objetivos del proyecto
Administrador:
Añadir, editar o eliminar el perfil de cualquier usuario.
Añadir, editar o eliminar los productos distribuidos.
Añadir, editar o eliminar las categorías de los diferentes productos.
Revisar todas las cestas que tiene registrado el sistema, tanto pendientes,
como finalizadas sin pagar, como pagadas.
Se podrá validar el pago de aquella cesta finalizada una vez recibido (la
factura del cual se generará, se enviará por correo electrónico al usuario y se
podrá consultar, tanto en el perfil del usuario como en el del administrador).
Para la edición, tanto de productos como de categorías se adaptará una
herramienta externa ya realizada como es CKeditor.
Una vez explicada la funcionalidad que se pretende aplicar a este proyecto, se pasará
a explicar la interfaz gráfica del usuario:
Tiene que ser sencilla y llamativa para que atraiga a los usuarios y prefieran
utilizar esta aplicación a un papel y un bolígrafo.
Tiene que ser clara y concisa, donde los usuarios puedan realizar sus compras
rápidamente sin ningún tipo de líos.
Tiene que estar preparada para cualquier tipo de tamaño de pantalla, ya que
los usuarios podrán ejecutarla desde cualquier navegador en cualquier
dispositivo.
11
Capítulo 2: Objetivos del proyecto
Por último se marcan unos objetivos claros de seguridad para el control de la sesión,
el control de los ficheros que el administrador pueda subir al servidor (imágenes de
productos) y control de la entrada de texto (principalmente en formularios). Éste último se
implementa mayormente para la parte de cliente (intentando así poder evitar ataques como
el Cross-site scripting).
12
Capítulo 2: Objetivos del proyecto
13
Capítulo 3: Especificaciones del proyecto
Esta distribución que incorpora los dos componentes esenciales del proyecto como es
Apache y MySQL se ha probado en Windows 7. No se ha probado el funcionamiento en
otras plataformas como Linux o Mac OS, pero es compatible con ellos, así que se intuye
que no habría ningún tipo de problema en instalar Xampp en estas plataformas.
14
Capítulo 3: Especificaciones del proyecto
15
Capítulo 3: Especificaciones del proyecto
16
Capítulo 4: Diseño
4 Diseño
En este apartado se detallarán las decisiones previas que se han tomado a la hora de
diseñar la aplicación. Se explicarán las diferentes partes, es decir, los diferentes módulos
del entorno Web como son el modelo, el controlador y la capa de presentación o vista,
junto con las tecnologías que se han utilizado y el motivo.
También se comentará la internalización de la aplicación para ampliar su expansión a
nivel internacional.
17
Capítulo 4: Diseño
18
Capítulo 4: Diseño
19
Capítulo 4: Diseño
En este tipo de aplicaciones, donde mayormente se quiere tener soporte para JSP /
Servlet, la elección del servidor no es tan decisiva e importante como otras. Además, Java
EE es un estándar y por lo tanto una aplicación EE desarrollada con un servidor de
aplicaciones podría migrarse a otro servidor sin excesivas complicaciones.
20
Capítulo 4: Diseño
21
Capítulo 4: Diseño
Por último, los productos (por parte de las imágenes y sus descripciones) también se
han seleccionado de la página original de esta empresa. Al igual que sus categorías.
Toda esta metodología que se ha explicado hasta ahora se ha realizado de esta
manera, no para ahorrarse trabajo a la hora de diseñar ya que el agente comercial es
distribuidor de productos de esta empresa y se pretende ofrecer esta aplicación a Nutrisport
para ayudar a sus agentes a mejorar en su metodología de trabajo del día a día.
22
Capítulo 4: Diseño
Una vez dicho esto, se quiere conseguir un entorno rápido, no sobrecargado con
información o elementos que no puedan interesar al usuario; es decir, el objetivo es un
equilibrio entre simplicidad y calidad de diseño para que el usuario se encuentre cómodo y
se acostumbre de manera más rápida al funcionamiento de la aplicación.
23
Capítulo 4: Diseño
24
Capítulo 4: Diseño
4.6 Internacionalización
El mercado informático es global y para competir es preciso hacer programas para
usuarios de todo el mundo (o en su defecto, para el abasto de la aplicación); por lo tanto la
internacionalización es una necesidad, no una opción.
La internacionalización, por definición, es el diseño y desarrollo de un producto, una
aplicación o el contenido de un documento de tal manera que permita una fácil
comprensión a audiencias de diferentes culturas, regiones o idiomas.
25
Capítulo 4: Diseño
4.8 Seguridad
La seguridad, en aplicaciones de este tipo es esencial, ya que se manejan muchos
datos de usuarios y empresa que requieren confidencialidad.
26
Capítulo 4: Diseño
Por lo tanto se tomarán las medidas preventivas necesarias para intentar eliminar
cualquier tipo de intrusión en el sistema. A continuación se explicarán las tres medidas que
se han tomado para dotar de seguridad este entorno web.
Control de archivos: Este tipo de prevención tiene como objetivo controlar
los ficheros que se vayan a cargar al servidor, es decir, a la base de datos. Se
tendrán que controlar el formato de archivos que se vayan a cargar, su
tamaño, entre otras. En el contexto de la aplicación, donde el administrador
podrá subir imágenes de los productos, se controlará que el formato de tales
sea ".jpg" y que su tamaño no sobrepase los 3 MB.
(Los métodos prácticos que se han utilizado para realizar lo explicado anteriormente
se encuentra en el capítulo de desarrollo).
27
Capítulo 4: Diseño
28
Capítulo 4: Diseño
Se realizó de esta manera por conveniencia del desarrollador ya que guardar las
imágenes directamente en la base de datos y intentar posteriormente acceder a ellas desde
la vista resultaba un tanto complicado.
Finalmente aclarar el concepto de path relativo (o ruta relativa) utilizado en esta
aplicación en cualquier método donde se haya necesitado introducir rutas de archivos; y es
que en cualquier aplicación web es obligatorio y no opcional utilizar este tipo de rutas, ya
que la absoluta puede llevar a crear grandes problemas de seguridad.
En la ruta relativa se llama a un archivo pero desde el lugar donde se está ejecutando el
servidor, es decir, solo funciona dentro de nuestro dominio. Por ejemplo: si se quiere
acceder a una factura temporal de este proyecto, solo se tendrá que determinar la ruta
relativa; en este caso /reports/temp/factura1.pdf.
29
Capítulo 5: Desarrollo
5 Desarrollo
En este capítulo se pasará a explicar la parte práctica del proyecto, junto con las
características, lenguajes de programación, aplicaciones y métodos que se han
implementado para construir este entorno.
La implementación se ha dividido en dos partes, por una parte se dividen los tres
módulos que forman el patrón MVC y se explican las características utilizadas y por otra
parte se explican otros detalles que complementan la aplicación.
5.1.1 Persistencia
El primer objetivo que se plantea es poder guardar los datos de los objetos, es decir
sus atributos, de forma persistente; mayormente en una base de datos relacional (BDR).
Los objetos que se utilizarán para acceder a estos datos guardados están explicados
posteriormente en la sección DAO.
Existen diferentes tipos de tecnologías para gestionar la persistencia en Java:
Serialización
Con un middleware como es JDBC (Java DataBase Connectivity)
Utilizando EJB (Enterprise Java Beans), una plataforma compleja y
estandarizada en la tecnología J2EE.
Con un framework de persistencia
5.1.2 JDBC
Para la gestión de persistencia de este proyecto se utilizó JDBC, el cual es un
middleware que permite a la aplicación Java conectar y acceder de una forma estándar
(independientemente del sistema operativo donde se ejecute, o de la base de datos a la cual
se accede siempre y cuando contenga el driver JDBC) a cualquier base de datos relacional.
Por lo tanto, el código de este intermediario entre la base de datos y la aplicación es
independiente al gestor utilizado; por lo tanto nos ofrece dos características
imprescindibles como son la portabilidad y la escalabilidad.
Este intermediario se encuentra en los paquetes de Java SDK: java.sql y javax.sql.
30
Capítulo 5: Desarrollo
31
Capítulo 5: Desarrollo
En el anterior ejemplo se hace una llamada a la base de datos para recoger cierta
información, pero si ésta se quiere modificar hace faltar utilizar el método
"executeUpdate", junto un String que use las sentencias SQL (update, insert o delete).
32
Capítulo 5: Desarrollo
Cerrar la conexión: Por último se cerrará la conexión con la base de datos; esta
función es bastante costosa por lo tanto se recomienda utilizar únicamente cuando se
esperen operaciones adicionales en la BD. Mediante el siguiente método se ejecutará esta
acción: connection.close();
En esta aplicación, se asignaron todos los beans al principio del desarrollo, ya que estos
nos servirían de guía para la creación de la base de datos y los objetos de acceso a los datos
que se implementarán a partir de ellos (explicados en el siguiente apartado).
33
Capítulo 5: Desarrollo
5.1.4 DAO
Una aplicación J2EE necesita acceder a un almacén de datos desde uno de sus
componentes (EJB, JSP/Servlet). Para tratar de implementar lo anterior se han
implementado DAO's (Data Access Object). Sus principales ventajas son:
Abstracción y encapsulamiento todos los accesos a la BD.
Gestión de la conexión con el almacén y las operaciones de selección y
modificación de datos.
Se creará una clase abstracta DAO general que contendrá todos los métodos para
establecer una conexión con la base de datos. A continuación se creará un DAO por Bean
(los cuales serán heredados de la general) y su correspondiente interfaz.
En otras palabras, si se tiene un DAO para las cestas, como por ejemplo CestaDAO, en el
cual estará definido un método getPrice() para que retorne el precio total de aquella cesta,
desde el controlador no se sabrá cómo está implementado, ni que base de datos utiliza.
Todo esto se parecería a tener una clase llamada Cesta rellenada con métodos static a los
cuales se llamaría cuando fuera necesario. Con esto se intenta centralizar todo el acceso a
la tabla Cesta, pero DAO va más allá de la centralización. ¿Cómo se resolvería el problema
de devolver un listado de cestas a través de su clase con métodos static?
34
Capítulo 5: Desarrollo
Ya que, por ejemplo el método GetCestas() devuelve un dataset rellenado con los coches, o
un datareader/recordset, o una lista separada por comas, o una estructura xml, o un array…
Los DAO incluyen otro concepto que son los DTO (Objetos de transferencia o Java Beans,
explicados anteriormente) que sirven únicamente para transportar datos. En este mismo
caso, este objeto sería CestaBean. Entonces, DAO, lo que devuelve es una lista genérica de
CestaBean o solamente una si se está buscando información de una sola cesta.
Por lo tanto, este bean contiene información de las propiedades de una cesta como son la
identificación del usuario, los diferentes productos, el precio total, etc. El patrón DAO, tras
una petición del controlador, rellena un DTO (Java Bean) o un conjunto de ellos y los
vuelve a devolver al controlador.
Todo esto explicado anteriormente tiene un objetivo claro y sencillo: conseguir 100% de
separación entre el Controlador y el Modelo. Ante cualquier cambio que se diera en la
forma de acceder a los datos, como por ejemplo que a partir de ahora en lugar de sacar las
cestas de una tabla cestas se hace desde un servicio web que retorna cestas, el modelo no
será consciente de este cambio, ya que lo que le va a seguir llegando va a ser siempre
CestaBean.
35
Capítulo 5: Desarrollo
5.1.6 Tuplas
Algunos objetos contenían información de otros objetos como podría ser su
identificador. En estos casos cuando se quería devolver información del objeto que
contenía el primero faltaban muchos datos, ya que solo se tenía un simple identificador.
Para esto se han creado tuplas de objetos, las cuales unen diferentes beans en uno solo y
ayudan a acceder a todas sus características en una única llamada.
Para ejemplificarlo, el objeto cesta, a su vez contiene el identificador del usuario al
que pertenece. La llamada a la función que devuelve una cesta aleatoria se necesita
también todos los datos del usuario y no solamente su identificador, con las tuplas se podrá
resolver este inconveniente. Ya que a la hora de devolver el objeto cesta, también enviará
el objeto usuario.
36
Capítulo 5: Desarrollo
37
Capítulo 5: Desarrollo
38
Capítulo 5: Desarrollo
Este valor retornado siempre será un String, de esta manera nos ayudará a identificar
mucho mejor las acciones; en el caso de no encontrar relación entre una acción y un valor
retornado se procederá a declarar un valor "input", el cual reenviará la aplicación a la vista
indicada.
En estas definiciones de las diferentes acciones también se pueden añadir los
interceptores, los cuales serán declarados al principio del fichero. Otra posibilidad es la
definición de las características que tendrán los diferentes parámetros en la acción. Por
ejemplo, a la hora de ejecutar la acción de "descargar factura" se definirá que el fichero
factura sea de tipo PDF, entre otras características.
En Struts.xml no solo se gestionan los direccionamientos sino que también se
declararán las variables globales de la aplicación como por ejemplo la variable del idioma
predeterminado o como se comentó en el párrafo anterior, los interceptores. También podrá
declararse un archivo de gestión de plantillas; en este caso se ha declarado "Tiles" como
sistema de plantillas, explicado en el apartado de la vista.
Por otro lado se han utilizado variables de sesión, las cuales se les asigna un valor y se
introducen en el contexto de la sesión del usuario mientras ésta esté activa. La
implementación de esta gestión de la sesión se ha llevado a cabo con "ActionContext".
39
Capítulo 5: Desarrollo
session.setAttribute("basket", id_basket);
HttpServletRequest request=ServletActionContext.getRequest();
HttpSession session=request.getSession();
Código 5. Almacenamiento de la variable cesta en el contexto de la aplicación
Cada contexto es básicamente un contenedor de objetos que una acción necesita para
ejecutarse como son la sesión del usuario, parámetros, la variable "locale" de aquella
sesión...). Por cada contexto que se crea, también se crea un thread, lo que significa que
cualquier valor almacenado en él es único.
SessionMap<String,String> sessionmap;
sessionmap.put("tipo","user");
sessionmap.put("user",aux.getEmail());
Código 6. Almacén de variables al inicio de sesión utilizando otro método llamado SessionAware
40
Capítulo 5: Desarrollo
Esta pila puede modificarse como se desee; por ejemplo, modificar el orden de
ejecución de los interceptores. Las funcionalidades que se han añadido gracias a los
interceptores son explicadas en los siguientes apartados.
<param name="maximumSize">2097152</param>
<param name="allowedTypes">image/png,image/gif,image/jpeg</param>
</interceptor-ref>
Código 5. Interceptor utilizado para la carga de imágenes al servidor
41
Capítulo 5: Desarrollo
42
Capítulo 5: Desarrollo
<validators>
<field name="name">
<field-validator type="requiredstring">
<message key="req.name" />
</field-validator>
</field>
<field name="price">
<field-validator type="required">
<message key="req.price" />
</field-validator>
<field-validator type="double">
<param name="minInclusive">1.0</param>
<param name="maxInclusive">10000.0</param>
<message key="req.price" />
</field-validator>
<field-validator type="regex">
<param name="expression"><![CDATA[^[1-
9]\d*(\.\d+)?$]]></param>
<message key="req.numeric"/>
</field-validator>
</field>
</validators>
43
Capítulo 5: Desarrollo
<s:form action="editarProducto">
<s:textfield label="nombre" name="nombre_producto" />
<s:submit value="Enviar" />
</s:form>
44
Capítulo 5: Desarrollo
En la figura 16 se muestran todos los tipos de tags existentes que nos proporciona el
framework Struts 2. En los casos anteriores se utilizaron, en el caso del formulario un tipo
de etiqueta para formularios y en el segundo caso un tipo de etiqueta para datos.
Figura 16. Todos los tipos de etiquetas que nos proporciona Struts 2
45
Capítulo 5: Desarrollo
Una de las etiquetas más utilizadas en esta aplicación es "accordion"; una utilidad
muy interesante para poder crear paneles de contenido plegables y desplegables para
presentar información en una cantidad limitada de espacio. Otra ventaja de utilizar esta
librería es que cargará el contenido que se encuentre dentro a la vez que carga el contenido
de la página general. Es decir, mantendrá al usuario en la misma página en lugar de cargar
otra página para que visite el contenido que se encuentra dentro del panel desplegable. El
ejemplo que se encontrará en el entorno inicial de la aplicación (Figura 17) será un
"accordion" que cargará la página de inicio de sesión y la página de registro en dos paneles
plegables.
Figura 17. Página de inicio y de registro en un panel desplegable dentro de la página general
46
Capítulo 5: Desarrollo
5.3.4 Tiles
Cuando se construye un entorno web dividido en diferentes partes (cabeceras, pies,
menús, cuerpo,...) se tiene que considerar el uso de una o más plantillas para reutilizar el
código estático y cambiar únicamente aquellas partes que suelen modificarse
mayoritariamente como suele ser el cuerpo de la página, es decir la porción central.
Las plantillas se basan en la estructura que tendrá la página web y contendrá los
elementos necesarios como acostumbran a ser: cabeceras, pies de página, menús, etc. Esto
nos ofrece muchas ventajas ya que si se quiere cambiar el contenido de estas partes de la
aplicación solamente se modificará de un fichero y el cambio se extenderá a todo el
sistema.
Para implementar este tipo de plantillas Struts tiene un complemento llamado Tiles,
el cual es utilizado en este proyecto. Primero de todo se tendrá que definir este
complemento en el archivo de configuración de la aplicación (web.xml) y a continuación
se definirá la plantilla (Código 9) en base a la construcción de tres elementos:
La plantilla que define elementos estáticos y áreas donde insertar otros
contenidos.
La página real que utiliza la plantilla insertando textos y otras porciones
dinámicamente..
Las porciones particulares reutilizables, en este caso serán otros JSPs.
47
Capítulo 5: Desarrollo
Con estos nuevos elementos será mucho más coherente y fácil de entender la
estructura por otras personas y lo más importante es que las máquinas también entenderán
su significado, dándole más importancia a unas secciones, entre otras funcionalidades.
Concretamente, facilitará la tarea de un buscador, pero cualquier aplicación que interprete
el código se beneficiará. Los elementos utilizados en este proyecto son:
Header: representa la cabecera de una sección, y se le dará más importancia
que al resto, sobre todo si la sección es un artículo.
48
Capítulo 5: Desarrollo
Por otro lado está la capacidad multimedia de HTML 5, uno de los grandes avances
en esta última versión del popular lenguaje de programación. En este proyecto se ha
implementado la etiqueta de vídeo, que nos evita la necesidad de recurrir a plugins de otras
aplicaciones como Flash. Esta etiqueta ya está incluida como un elemento natural más de
HTML y cuenta con unos atributos que hacen mucho más flexible la utilización de un
vídeo.
Para poder utilizar esta funcionalidad hace falta que todos los navegadores estén
preparados para reproducir el vídeo que viene integrado en el código HTML5; el único
interrogante que falta por resolver es el formato estándar que todos los navegadores
tendrían que implementar. La presentación de vídeos se puede realizar mediante la etiqueta
<video>, dotada de diferentes atributos para su configuración.
Uno de ellos es la especificación del formato del vídeo a reproducir ya que, como se dijo
antes, no existe un acuerdo para implementar un formato de vídeo estándar. Los atributos
más importantes son:
49
Capítulo 5: Desarrollo
Aquí es donde entra en acción la técnica de los “media queries”. Gracias a ella se
puede modificar el modo en que se visualiza la estructura del entorno web en distintos
dispositivos. La regla @media (implantada en esta última versión de CSS) permite añadir
media queries directamente en nuestras hojas de estilo. De esta manera se mejorará el
rendimiento de la página al no tener que cargar archivos CSS adicionales para los
diferentes dispositivos.
5.3.6 Scripts
A la hora de implementar la aplicación web se han utilizado algunos scripts
(Javascript) de código abierto para la visualización de contenido y otros, también de código
abierto, para mejorar su funcionalidad como es el caso del elemento explicado en el
siguiente capítulo.
5.3.6.1 CKeditor
A la hora de editar ciertas partes de la web como son los productos o categorías se
requería un editor que incorporara algunas funcionalidades para facilitar la administración
de estas partes al usuario; ya que utilizando un elemento textarea se podrían escribir
descripciones o textos con un contenido y un formato no muy adecuado.
Es aquí donde se ha decidido implementar CKeditor: un editor de textos HTML de
código abierto que provee al usuario una edición de contenidos a la altura de aplicaciones
de escritorio (Microsoft Word) sin la necesidad de instalar ningún componente en la
máquina del cliente.
50
Capítulo 5: Desarrollo
5.4 I18n
Lo habitual en Struts es utilizar ficheros de texto plano como son los ".properties",
gestionados mediante ResourceBundle) para definir cadenas de textos que tienen que ser
internacionalizadas junto a una clave única para poder recuperar dicha variable o cadena.
Por lo tanto se utilizará un fichero de propiedades para cada uno de los idiomas que
se implantarán en el sistema. En los nombres de los archivos se debe especificar el idioma
indicando el prefijo de ese fichero en el struts.xml; es muy habitual usar “global”. Junto a
este prefijo se adjuntará el sufijo del idioma a utilizar mediante su código correspondiente.
Para el fichero de idioma catalán se especificará el siguiente nombre: global_ca.properties.
Estos ficheros deberán localizarse en la carpeta general o por defecto que crea el
proyecto Struts 2. Un ejemplo del contenido de uno de estos ficheros ".properties" donde
se especifica un clave para una variable y un valor es el siguiente:
Global_ca: field.add_category = Afegir categoria
Global_es: field.add_category = Añadir categoría
Global_en: field.add_category = Add category
<s:text name="field.add_product"/>
<s:submit value="%{getText('field.edit')}"/>
Código 13. Métodos para acceder desde el JSP a las variables del fichero propiedas de idiomas.
51
Capítulo 5: Desarrollo
5.5.1 JasperReports
Para poder implementar las facturas en un entorno de programación J2EE se ha
utilizado la herramienta JasperReports; una librería escrita completamente en Java que
permite la creación de informes y exportarlos directamente a diferentes formatos (PDF,
HTML, XML...).
La plantilla de un informe contiene toda la información (determinar la posición del
contenido de los textos, elementos gráficos, etc.) relacionada con la estructura y el aspecto
de los documentos que se generarán posteriormente. Además, toda la forma en la que se
gestionan y manipulan los datos para acceder a almacenes externos de datos también estará
definida en la plantilla.
Este template está programado en el lenguaje XML, el cuál es nombrado como
JRXML en la librería Jasper. Una vez creado, JasperReports procede a validar su
contenido (estructura y sintaxis) mediante un archivo DTD (Document Type Definition) y
generar automáticamente la versión compilada del informe.
5.5.2 iReport
JasperReports acostumbra a usarse con iReport, una herramienta que ayuda a la
edición de los informes mediante un editor gráfico, permitiendo la inclusión de cualquier
elemento (gráficos, imágenes...). Está desarrollado en Java y también es de libre
distribución. Las principales características por las que se ha decidido utilizar iReport son
las siguientes:
Implementa el 90% de las etiquetas de JasperReports.
Permite diseñar con sus propias herramientas una gran variedad de elementos
gráficos.
Soport JDBC.
Soporta Javabeans como origen de datos.
52
Capítulo 5: Desarrollo
53
Capítulo 5: Desarrollo
JasperReport masterReport =
JasperReport)JRLoader.loadObjectFromFile(contextReport);
JasperPrint Print =
JasperFillManager.fillReport(masterReport,pars,conexion);
54
Capítulo 5: Desarrollo
// creates multi-part
Multipart multipart = new MimeMultipart();
multipart.addBodyPart(messageBodyPart);
MimeBodyPart attachPart = new MimeBodyPart();
attachPart.attachFile(file);
multipart.addBodyPart(attachPart);
}
Código 15. Código Java para el envío de la factura por email al cliente
55
Capítulo 5: Desarrollo
56
Capítulo 6: Evaluación
6 Evaluación
A continuación se procederá a comprobar el funcionamiento de la aplicación. Se
realizará de igual manera a su desarrollo, es decir, capa por capa del patrón MVC y su
seguridad. En este proyecto no se realizarán pruebas unitarias, se realizará una evaluación
centrada en comprobar el correcto funcionamiento de las diferentes partes y las diferentes
funcionalidades que ésta ofrece.
Por último, para asegurarse al máximo su funcionamiento se ha pedido a diferentes
usuarios utilizarla y realizar todo tipo de funciones dentro de ella para poder recoger
opiniones y posibles fallos y proceder a su solución; este apartado se explicará en la última
parte de este capítulo.
Figura 21. Mensaje de error al intentar registrar un email ya existente en la base de datos
57
Capítulo 6: Evaluación
Las pruebas anteriores también permiten ver que el modelo de datos utilizado (DAO)
realiza su función correctamente junto con los objetos de transferencia de datos (beans)
implementados. Todas estas pruebas se realizaron con una interfaz gráfica muy sencilla, es
decir, sin haber desarrollado la capa de la vista totalmente.
Figura 22. Validación de los campos de Email y contraseña en la acción de iniciar sesión.
58
Capítulo 6: Evaluación
59
Capítulo 6: Evaluación
60
Capítulo 6: Evaluación
Figura 26. Página de contacto de la aplicación con Google Maps y un formulario de contacto.
61
Capítulo 6: Evaluación
Figura 28. Panel de usuario: las diferentes cestas realizadas ordenadas por fecha.
62
Capítulo 7: Conclusiones
7 Conclusiones
Una vez finalizado el proyecto y su evaluación se han sacado una serie de
conclusiones, las dividiremos según los objetivos fijados al principio y se acabará
explicando las valoraciones personales que el desarrollador de la aplicación ha conseguido
extraer de todos los meses de trabajo realizado.
63
Capítulo 7: Conclusiones
64
Capítulo 8: Recursos utilizados
8 Recursos utilizados
8.1 Bibliografía
[1] Web en línea <> http://www.javatpoint.com [Consulta: Octubre 2013]
[2] Web en línea <> http://www.java4s.com [Consulta: Octubre 2013]
[3] Web en línea <> http://www.epidataconsulting.com [Consulta: Octubre 2013]
[4] PDF en línea <> http://es.scribd.com/doc/52029539/TEMA-8-2-Struts2
[Consulta: Diciembre 2013 ]
[5] Foro de usuarios en línea <> http://stackoverflow.com [Consulta: Enero 2014]
[6] Web en línea <> http://www.mkyong.com/struts2 [Consulta: Octubre 2013]
[7] Web en línea <> http://www.tutorialspoint.com/struts2 [Consulta: Octubre 2013]
[8] Web en línea <> http://www.javatutoriales.com [Consulta: Agosto 2013]
[9] Web en línea <> http://www.tutorials4u.net [Consulta: Septiembre 2013]
[10] Web en línea <> http://mrbool.com [Consulta: Febrero 2014]
[11] Web en línea <> http://viralpatel.net/blogs/struts-2-tiles-plugin-tutorial
[Consulta: Febrero 2014]
[12] Web en línea <> http://struts.jgeppert.com/struts2-jquery-showcase/
[Consulta: Abril 2014]
[13] Web en línea <> https://developer.mozilla.org/es/docs/CSS/Media_queries
[Consulta: Abril 2014]
[14] Web en línea <> http://community.jaspersoft.com/project/ireport-designer
[Consulta: Agosto 2013]
[15] Web en línea <> http://struts.apache.org/release/2.3.x/docs/home.html
[Consulta: Agosto 2013]
[16] Web en línea <> http://www.w3schools.com [Consulta Marzo 2014]
65
Capítulo 8: Recursos utilizados
66
Capítulo 9: Anexos
9 Anexos
9.1 Manual de instalación y configuración
En primer lugar se instalará el servidor de aplicaciones, la base de datos y la
herramienta para interactuar con la base de datos de manera gráfica en lugar de utilizar
comandos. Para instalar todo lo anterior solamente se tendrá que instalar la herramienta
XAMPP, que incluye las herramientas anteriores, desde la siguiente dirección:
https://www.apachefriends.org/es/index.html
Donde "user" será el nombre de usuario y "pw" será contraseña para este usuario. Se
han añadido los roles "standard" y "manager", es decir, los permisos suficientes para
administrar el servidor. Tras añadir esta línea se tendrá que detener e iniciar el servicio de
Tomcat. La contraseña se guarda no encriptada, por lo que hay que tener cuidado y saber
que usuarios pueden acceder a este archivo de configuración.
67
Capítulo 9: Anexos
En netbeans se tendrá que crear una aplicación J2EE donde se indicará el framework
MVC a utilizar (Struts 2) y el servidor que se utilizará, ya que por defecto si no se indica
uno utilizará GlassFish. En este caso se indicará Tomcat. Las librerías que se incorporarán
al proyecto son las siguientes:
commons-beanutils-1.8.0.jar
commons-digester-1.8.jar
commons-collections-2.1.1.jar
commons-javaflow-20060411.jar
commons-lang-2.6.jar
freemarker-2.3.15.jar
javax.mail.jar
junit-3.8.2.jar
struts2-jquery-plugin-3.6.1.jar
struts2-tiles-plugin-2.1.8.jar
tiles-core-2.0.6.jar
xwork-core-2.1.6.jar
jasperreports-5.5.0.jar
jasperreports-applet-5.5.0.jar
jasperreports-fonts-5.5.0.jar
jasperreports-javaflow-5.5.0.jar
swing-worker-1.1.jar
groovy-all-2.0.0.jar
iText-2.1.0.jar
A la hora de crear la base de datos MySQL y las diferentes tablas que la forman se
realizará mediante la herramienta phpMyAdmin. En el caso que no se sepan los comandos
correctos "sql" este programa solventará este problema. Para acceder a esta herramienta se
hará mediante el navegador en la dirección:
http://localhost/phpmyadmin
68
Capítulo 9: Anexos
9.2.1 Administrador
El usuario administrador solo podrá conectarse al entorno web con los datos
proporcionados por el desarrollador, es decir, con el correo electrónico y una contraseña
proporcionada, que posteriormente podrá cambiar en su perfil. En el caso de no introducir
los datos correctos o no tener permisos de administrador, el usuario permanecerá en la
misma página inicial de la aplicación.
Figura 29. Página de inicio para iniciar sesión, tanto de administradores como de clientes
69
Capítulo 9: Anexos
Figura 31. Página para editar los usuarios registrados (clientes) en el sistema.
Figura 32. Página para añadir, editar o eliminar los productos de empresa introducidos en el sistema.
Categoría: Se podrán realizar las mismas acciones que en los productos con la
misma restricción de no permitir dos categorías con el mismo nombre.
70
Capítulo 9: Anexos
Cestas sin confirmar: Son las cestas que los usuarios aun tienen pendientes
de finalizar ya que por algún motivo no pudieron confirmarlas. Estas cestas
no son de gran importancia para el agente comercial ya que no tendrá que
realizar ninguna acción.
Cestas confirmadas: Son las cestas que los usuarios ya acabaron por lo tanto
el agente comercial tendrá que preparar los pedidos correspondientes de
productos y una vez pagadas se procederá a realizar el método "Validar pago"
donde automáticamente se generará una factura que será enviada al cliente
por correo electrónico y podrá ser accedida por él desde su panel de usuario.
Cestas pagadas: Son aquellas cestas que ya han sido confirmadas y pagadas.
Se podrá consular la factura de todas ellas.
Figura 34. Cestas confirmadas y pagadas donde se podrá descargar el informe correspondiente.
71
Capítulo 9: Anexos
9.2.2 Cliente
Al igual que con el caso del administrador, el usuario cliente tendrá que entrar al
sistema mediante un correo electrónico y una contraseña proporcionada en este caso por el
administrador y no el desarrollador de la aplicación. Si no se introducen los datos correctos
el cliente permanecerá en la pantalla de inicio sin poder utilizar las funciones de la
aplicación.
En la página principal del cliente se podrá realizar las siguientes funciones:
Perfil de usuario: Modificará sus datos personales, donde podrá cambiar el
correo electrónico de contacto, el teléfono, contraseña, etc.
Productos: Podrá visualizar todos los productos que contiene el sistema. Para
ver la descripción, categoría a la que pertenecen y su precio deberán dar clic
encima de la imagen del producto y se abrirá una ventana con tal
información.
72
Capítulo 9: Anexos
Figura 36. Lista de cestas confirmadas por fecha. Se muestra una cesta pagada con el correspondiente
enlace para descargar la factura
Cestas sin confirmar: Se mostrarán todas aquellas cestas que el usuario dejará
pendientes de confirmar. Estas cestas podrán editarse para finalizarlas en el
momento que el usuario desee.
73
Capítulo 9: Anexos
74
Capítulo 9: Anexos
75