Práctica 8: Noticias Web

1. Es necesario aprobar esta práctica para aprobar la asignatura.
2. La práctica debe ser entregada estrictamente en el plazo estipulado. No se ampliará el plazo de entrega de la práctica.
3. La práctica debe realizarse y entregarse por parejas. Aquellos alumnos que no tengan pareja, o cuya pareja renuncie a trabajar en la práctica, deben hablar con los profesores de la asignatura. Sólo se admitirán entregas individuales en aquellos casos que hayan sido autorizados previamente por los profesores.
4. Las parejas deben ser las mismas que en la práctica de Swing, salvo en situaciones excepcionales (por ejemplo, abandono de la asignatura o falta de colaboración de alguno de los alumnos), que deben ser comunicadas a los profesores con la mayor antelación posible.
5. Cada pareja utilizará la misma base de datos que en la práctica de Swing.
6. Las entregas deben funcionar en los ordenadores del Depto. de Ingeniería Telemática (sistema operativo Linux) de los laboratorios en que se imparten las clases prácticas, con las bases de datos proporcionadas.
7. Para que la práctica sea evaluada, es imprescindible que sus autores se presenten a la entrevista de evaluación de la misma en la fecha y la hora convenidas. Dado que la evaluación tendrá lugar durante el período de exámenes, se pactarán las fechas más convenientes con los alumnos.
8. La calificación de esta práctica se conserva, si el alumno lo desea, para la convocatoria de septiembre.
9. Las prácticas a entregar en la convocatoria de septiembre serán las mismas que en la convocatoria de febrero.

En esta práctica se desarrollará el portal Web del sistema de gestión de noticias. Fundamentalmente, este portal permitirá a los usuarios del sistema ver las noticias, escribir y leer comentarios y votar en aquellas noticias que tengan una votación asociada.

El portal Web debe proporcionar, como mínimo, las siguientes vistas y funciones:

1. Control de acceso y cierre de sesión: algunas de las funciones del portal requieren que el usuario esté autenticado. El sistema debe permitir, a los usuarios que lo deseen, autenticarse con su alias y contraseña. La autenticación debe ser válida hasta que se cierre o caduque la sesión. Los usuarios que se hayan autenticado deben poder cerrar su sesión.
2. Portada: la portada es el recurso inicial que se encuentra un usuario al acceder al portal. Debe mostrar, al menos, lo siguiente:
   • Últimas noticias del sistema (por ejemplo, la(s) última(s) de cada categoría). Es suficiente con mostrar el título de cada una de las últimas noticias, enlazando a la vista de la noticia.
   • Enlaces a la portada de cada categoría.
   • Gestión de autenticación: desde la portada debe ser posible autenticarse en el sistema. También se debe mostrar, si el usuario está autenticado, su alias o nombre completo.
3. Portada de categoría: cada categoría dispondrá de una portada en la cual, como mínimo, se debe mostrar el título de las últimas noticias de dicha categoría, así como alguna forma de acceso al archivo de noticias (sólo para usuarios autenticados).
4. Vista de noticia: muestra el texto completo de una noticia, así como sus metadatos (fecha, autor, título) y sus comentarios ordenados cronológicamente.
   • Debe permitir a los usuarios autenticados introducir un nuevo comentario.
   • Si la noticia tiene una votación asociada, y la fecha es compatible con el intervalo en que se puede votar, debe permitir a los usuarios autenticados votar. Por sencillez, no es necesario controlar que cada usuario sólo vote una vez.
5. Vista de archivo de noticias: muestra un listado completo de las noticias del sistema, clasificadas por categoría. Esta vista es accesible sólo a los usuarios autenticados.

La aplicación desarrollada, además de proporcionar la funcionalidad mínima que se pide, debe cumplir los siguientes requisitos:

1. Todos los documentos HTML generados deben ser válidos con respecto a la especificación de XHTML 1.1.
2. Debe utilizar CSS para establecer el estilo de las páginas generadas.
3. Debe organizar las clases en paquetes.
4. Debe permitir que múltiples usuarios realicen operaciones simultáneamente.
5. Todas las URLs utilizadas deben ser relativas, salvo en casos en que esté justificado el uso de una URL absoluta.
6. La aplicación debe funcionar independientemente de cuántas o qué categorías de noticias haya en la base de datos. Sin embargo, en el diseño de la portada se puede asumir que el número de categorías será razonable (por ejemplo, no más de diez).

Adicionalmente, se propone la realización de tareas opcionales, que serán tenidas en cuenta en la evaluación, pero no son necesarias para obtener el aprobado en la práctica. Cada una de estas funciones adicionales será valorada de acuerdo con su complejidad

1. Diseñar la aplicación Web de tal forma que reutilice la mayor cantidad posible de código de la aplicación Swing.
2. Separar las tareas de procesado de peticiones y obtención de resultados de las tareas de presentación de resultados. Las primeras debes realizarlas mediante servlets. Las de presentación, mediante documentos JSP. Como norma general, los servlets no deberían generar código XHTML, mientras que los documentos JSP deberían tener la menor cantidad de código Java posible. La forma de trabajo recomendada, para tareas que impliquen procesado (por ejemplo, interacción con la base de datos) es la siguiente:
   • Un servlet recibe la petición del usuario, la procesa y genera los resultados.
   • El servlet pasa el control a un documento JSP mediante el mecanismo de forward. Le puede pasar la información a mostrar como beans introducidos como atributos del objeto HttpServletRequest.
   • El JSP recupera estos beans y genera la presentación de los resultados.
3. Programar un servlet por cada operación básica, en vez de un servlet que se encargue de varias operaciones distintas.
4. Escribir trazas mediante el método log de las clases ServletContext o GenericServlet para depurar la aplicación. Las trazas serán accesibles en el directorio logs de la instalación de Tomcat. También se puede depurar la aplicación (puntos de ruptura, ejecución paso a paso, visualización del contenido de las variables, etc.) mediante Eclipse (con plug-in WTP, ya instalado en los laboratorios) y otros entornos de desarrollo avanzados.
5. Utilizar siempre URLs relativas para que la aplicación sea totalmente portable. Para facilitar esto, es recomendable acceder a los JSPs y servlets al mismo nivel de URL. Esto puede hacerse declarando el servlet-mapping de los servlets como (es un ejemplo) "/CrearIncidencia", pero no como "/servlet/CrearIncidencia".

Se entregará un único fichero con la extensión .war (comprimido con JAR), que contenga la aplicación web lista para ser desplegada (con todos los ficheros de configuración, clases compiladas, imágenes, hojas de estilo, etc.) Adicionalmente, en el directorio WEB-INF/src del fichero WAR se incluirá el código fuente de todas las clases Java utilizadas.

El fichero WAR contiene toda la estructura de la aplicación Web comprimida desde dentro del directorio principal de la misma:

cd ${CATALINA_HOME}/webapps/noticias/
jar cvf noticias.war *

Para reducir el tamaño de la entrega, este fichero no debe contener datos innecesarios como los siguientes:

• El fichero JAR del conector de JDBC, si se usa el recomendado en este enunciado.
• Ficheros de copia de seguridad generados por algunos editores (por ejemplo, *.bak, *~, #*, etc.).

Independientemente de que se haya desarrollado la aplicación en un entorno integrado como Eclipse o NetBeans, los autores de la práctica deben ser capaces, el día de la entrevista de evaluación, de compilar su aplicación desde línea de comandos. Aquellos que no sepan hacerlo pueden preguntar a los profesores en las prácticas o en tutorías, antes de vencer el plazo de entrega.

La calificación obtenida en esta práctica estará entre 0 y 10, y supondrá un 25% de la calificación final en la asignatura. Es necesario aprobar esta práctica (obtener al menos un 5) para aprobar la asignatura.

Parte de la evaluación se basará en una entrevista personal de los profesores con los autores de la práctica, que se realizará con cita previa. Los dos miembros de la pareja de prácticas deben demostrar conocimientos suficientes de la práctica que hayan entregado.

Además de que se implemente correctamente la funcionalidad obligatoria, se tendrán en cuenta los siguientes aspectos en la evaluación:

• Funcionalidad opcional implementada, tanto la propuesta en este enunciado como la desarrollada a iniciativa de los alumnos.
• Calidad y elegancia del diseño y código de la aplicación. Uso adecuado de la orientación a objetos. Gestión de errores adecuada.
• Usabilidad de la aplicación.

Para obtener una calificación de 5 o superior es necesario implementar la funcionalidad mínima expuesta en este enunciado. Por otra parte, un programa que implemente sólo la funcionalidad mínima puede optar hasta una calificación máxima de en torno a 8 teniendo en cuenta el resto de aspectos a valorar. El resto de la calificación, hasta 10, puede obtenerse implementando funcionalidad opcional.

XHTML/HTTP: