-Una relación many to many bidireccional, da problemas, muchos.
-Cambiar una many to many bidireccional por una one to many es engañar a la aplicación, y la práctica dice que no funciona, el dominio no es así.
-Lo ideal sería tener una relación many-to-many unidireccional, como indica la figura:

Relación many to many bidireccional

Por poner un ejemplo real del AMPA, lo ilustraré con la relación que existe entre un enlace y una categoría de enlaces. Una categoría puede tener muchos enlaces, y a su vez, un enlace puede estar en muchas categorías. No obstante, que el propio enlace sepa cuales categorías son sus contenedoras, no interesa, y sí al contrario; es deseable que la categoría de enlaces lleve un recuento de cuántos enlaces contiene.

Aquí, la entidad A sería la clase CategoriaEnlace y la entidad B, la clase Enlace. El mapeo en CategoriaEnlace de la colección de enlaces sería como sigue:

/**
* Enlaces de la categoría.
*/
@ManyToMany(fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH } )
@JoinTable(name=”categoriaenlace-enlace” joinColumns={@JoinColumn(name=”categoriaenlace_id”)},
inverseJoinColumns={@JoinColumn(name=”enlace_id”)})
private Set enlaces = new HashSet();

La cascada se define así puesto que así necesita el dominio que actúe. Si se graba/actualiza una categoría de enlaces con enlaces que no estén persistidos, se persisten mediante la cascada. No obstante, si se borra una categoría de enlaces, sus enlaces no se borran.

Los enlaces tienen un ciclo de vida independiente al de las categorías. Se pueden insertar, borrar, modificar enlaces independientemente de las categorías que existan. No obstante, cabe destacar una salvedad: El desarrollador se encarga, en caso de que se desee borrar un enlace vinculado a categorías, de que se desvinculen esas relaciones (y por tanto, mantener la tabla intermedia categoriaenlace-enlace) .

/**
* {@inheritDoc}
*/
public void borrarEnlace(Enlace enlace) throws EntidadNoPerteneceException {
// Comprobar que los parámetros no son nulos.
if (enlace == null) {
throw new IllegalArgumentException(
DefaultGestorEnlacesImpl.FMT_NULL_PARAMETER
.format(new String[] { “enlace” }));
}

// Desvincular el enlace de las categorías a las que está asociado.
List categorias =
this.ampaDao.buscarCategoriasContenedorasDeEnlace(enlace);
for (CategoriaEnlace categoria : categorias) {
categoria.quitarEnlace(enlace);
this.actualizarCategoriaEnlace(categoria);
}

this.getEnlaceDao().makeTransient(enlace);
}

Lo mismo para borrar una categoría, se desvinculan sus enlaces asociados y se pasan a una categoría “global”, de nombre General:

/**
* {@inheritDoc}
*/
public void borrarCategoriaEnlace(CategoriaEnlace categoria) throws EntidadNoPerteneceException {
// Comprobar que los parámetros no son nulos.
if (categoria == null) {
throw new IllegalArgumentException(
DefaultGestorEnlacesImpl.FMT_NULL_PARAMETER
.format(new String[] { “categoria” }));
}
//Desvinculamos los enlaces que tiene y los pasamos a la categoría GENERAL.
CategoriaEnlace categoriaGeneral = this.categoriaEnlaceDao.findById(1l);
categoriaGeneral = this.cargarEnlacesPorCategoria(categoriaGeneral);
for(Enlace e:categoria.getEnlaces()){
categoria.quitarEnlace(e);
try {
categoriaGeneral.agregarEnlace(e);
} catch (EntidadPerteneceException e1) {
//No se hace nada, no se agrega a la categoría porque ya lo tenía.
}
}
categoriaGeneral = this.categoriaEnlaceDao.makePersistent(categoriaGeneral);
categoria = this.categoriaEnlaceDao.makePersistent(categoria);
this.getCategoriaEnlaceDao().makeTransient(categoria);
}

Hay que tener muy en cuenta este detalle si no queremos que la base de datos se queje al intentar borrar entidades.

Hasta que descubrí Jetty, y, lo que es más, el potentísimo plugin para Jetty de Maven. Es una pasada, entre las múltiples ventajas que le he encontrado destaco tres:

-El desarrollador no tiene que preocuparse por instalar el servidor , nada. Lanzando la rutina maven mvn jetty:run, maven se lo baja, si no existe, y lo instala. Las siguientes veces que se ejecute esta rutina, ya estará en el repositorio local, con lo cual se lanza y listo.

-Los cambios del código se despliegan en caliente. El desarrollador puede ir escribiendo-probando-escribiendo-probando-escribiendo-probando, así hasta el infinito, sin paradas de servidor, rearranques, etc, etc…

-Posibilidad de debuguear el código. Mediante unos sencillos pasos, explicados en este tutorial, se configura el eclipse para poder debuguear el código.

Conclusión: un 10 al Jetty y al plugin de Maven.

Otra característica de Maven que he descubierto recientemente es la opción -o, que permite usar Maven en modo offline. Ideal cuando no se desea que se baje cosas nuevas de los repositorios que dicta el pom, o para trabajar con Maven sin conexión a Internet.

-Anteproyecto. Firmamos el anteproyecto y lo dejamos listo para entregar.
-Tema de socios del AMPA. Cada cuanto se paga la cuota (anualmente) y el importe de la misma, 12 € por familia, independientemente del número de hijos y de la edad de los mismos.
-Cómo debo enfocar la documentación del proyecto.

En un entorno de desarrollo, directamente la directiva de Maven mvn eclipse:clean eclipse:eclipse no funcionaba. Eso pasaba al meter la dependencia del servicio del AMPA:

ampa
ampa-service
1.0-SNAPSHOT

Aparte de todo esto, en el mismo entorno con MyEclipse, el plugin que trae para Tomcat no funcionaba correctamente. La aplicación se quedaba a medio desplegar y al abrir el navegador, no se mostraba.

Desde otro entorno diferente, menos que más, pero ocurrían los siguientes problemas. Aquí, Maven funcionaba correctamente, pero los problemas estaban al desplegar en MyEclipse. El plugin para Tomcat que trae incorporado funcionaba aún peor que en el primer entorno, con lo que decidí dejar de usar MyEclipse.

Me instalé un Eclipse normal, con el plugin de Tomcat Sysdeo. Para instalarlo leí alguna documentación, como este tutorial. El plugin en este caso funcionaba correctamente, pero seguía habiendo problemas al intentar desplegar desde él aplicaciones web creadas con Maven. Aparentemente se desplegaban correctamente, pero al poner la url en el navegador, mostraba un mensaje de recurso no disponible.

Con lo cual, como último recurso opté por desplegar a la vieja usanza. Con el comando de maven mvn package, se genera el .war y se tira en la carpeta de despliegue del Tomcat. Fin. Punto.

Tras descubrir Icefaces, particularmente el potente set de componentes que ofrece, se tomó un rumbo en cuanto a qué implementación JSF emplear.

La implementación inicialmente elegida hubiese sido MyFaces, poniendo como más potente argumento a favor el tema de la accesibilidad.

No obstante, tras consultar y estudiar mucha documentación, se ha llegado a la conclusión que el uso de MyFaces no garantiza plenamente la obtención de páginas accesibles. Es más, difícilmente se puede superar el nivel AA de conformidad , aún modificando manualmente el código generado.

Con lo cual, la solución de facto que se ha propuesto es hacer las páginas públicas (que puede consultar todo el mundo) lo más accesibles que sea posible. Por otro lado, aprovecharnos de las grandes ventajas que ofrece Icefaces para el desarrollo de la parte privada del sitio (que sólo consultará el administrador), no centrando en ésta total atención en cuanto a accesibilidad.

Como ejemplos de componentes a medida ya desarrollados, encontramos decenas, tales como:

-Editores de texto enriquecidos.
-Cantidad de funcionalidades sobre tablas (columnas ordenables, tablas con paginación…)
-Paneles popup.
-Formularios de carga de ficheros adjuntos.
-Etc…

Facelets tiene una extensa documentación a disposición del desarrollador, para consultarla seguir este link

Para configurar la aplicación para el uso de Facelets, he seguido este tutorial, que explica punto por punto los pasos necesarios para configurar la aplicación con el objetivo de usar este framework.

También me ha parecido interesante este artículo, que explica cómo configurar el IDE de desarrollo (en el artículo, Eclipse Europa), para tener disponible la opción autocompletar usando facelets (normalmente, el soporte de los ide´s para facelets es muy pobre).

Lourdes me hizo llegar los comentarios que le habían hecho estas personas al respecto, los cuales resumo junto con otros comentarios realizados por compañeros de trabajo y amigos:

-La búsqueda debe ocupar un lugar menos preferente en la página, quizás con un cuadro más pequeño y sustituir el botón por una imagen más discreta.
-Sustituir el título de la página o acompañarlo por una imagen que vaya acorde con el propósito del sitio.
-No repetir opciones en el menú superior e inferior (por ejemplo: Portada en ambos sitios)
-Migas: Sustituir el “Está usted en >Inicio>Estatutos” por “Está usted en : Inicio>Estatutos”.
-Criticada la sección de Ayuda en el menú más superior (pero hemos decidido mantenerlo debido a la inexperiencia de los usuarios, sobre todo aquellos que deban administrar algún contenido)
-Cuidar la presentación, estilos y acompañarlo de algún icono explicativo (Ejemplo: si en una novedad añadimos un icono con aspecto de calendario, precediendo a la fecha de publicación de la novedad y el autor, queda mucho más “resultón”).
-El menú izquierdo de usuario logueado se va a eliminar. En “el hueco” que deja se pondrá información que los miembros del AMPA creen ha de estar siempre visible, como son los datos de contacto y horario de apertura. Por consiguiente, se eliminará esta opción (contacto) del menú más superior.
-El usuario logueado ya no verá este menú que mencionaba en el punto anterior, sino que se habilitará un enlace a la zona privada del sitio. En esta zona aparecerá una pantalla de administración con un tabbed pane por cada opción a administrar (Ejemplo: pestañas usuarios, enlaces, actividades extraescolares, grupo deportivo)

Otro punto a tratar ha sido el de los roles de usuario. Una vez decididos a utilizar Spring Security para gestionar la securización, se han definido los siguientes roles de usuario:

-ADMINISTRADOR TOTAL: Tiene permisos sobre todos los contenidos de la página. Es el rol que normalmente ocupará Lourdes en un futuro. Es el único perfil que puede administrar y dar de alta usuarios.
-ADMINISTRADOR DE CONTENIDOS: Podrá administrar algún contenido de la página (Ejemplo: La profesora que da de alta y modifica los contenidos de la actividad extraescolar ballet). No podrán borrar contenidos.
-USUARIO GENERAL: No están registrados como tal en el sistema. Sólo tienen posibilidad de ver los contenidos publicados.

Por lo anteriormente comentado al respecto de la seguridad, un usuario no podrá registrarse en la aplicación (no habrá un servicio de registro). Todos los usuarios registrados lo han de ser debido a que el ADMINISTRADOR TOTAL los almacene en el sistema y por tanto se persistan en base de datos.

Los siguientes puntos también se han tratado en la reunión:

-Dar opción al usuario a estar siempre al tanto de las últimas novedades publicadas, por ejemplo haciéndole llegar las últimas publicaciones al correo. Yo he pensado solucionar esto mediante la creación y actualización automática de un feed RSS, que el usuario puede consumir.

-Introducción de una nueva entidad en el dominio. Las actividades pertenecientes al grupo deportivo se pueden agrupar (Ejemplo: en fútbol, benjamines, alevines, cadetes…)

-Los enlaces, como se había comentado por alto en alguna reunión precedente, se podrán agrupar por categorías. De esta forma será más facil agruparlos en el menú desplegable horizontal. Queda pendiente definir dichas categorías o la forma de administrarlas.

-Los contenidos de las páginas estáticas, como pueden ser Estatutos, Junta directiva…no se almacenarán en ficheros de propiedades de cara a la internacionalización, sino que irán en base de datos. Para poder editarlos, se estudiará el uso de algún editor Javascript, del estilo de Tiny Editor, que te genera código html accesible. De cara a la accesibilidad del sitio, habría que pensar una alternativa accesible a este método (por ejemplo, tener una sección en la zona privada que te permita editar mediante text-areas este contenido)

-Reportes e informes. Se plantea la posibilidad de sacar toda la información anual del AMPA a ficheros excel o pdf mediante el uso de apis como pueden ser Apache POI o Jasper Reports.

-Uso de la API Google. Particularmente, se ha pensado usar esta API en los siguientes ámbitos:
* Para información de estadísticas de visitas, Google Analytics.
* Para información de localización del colegio, Google Maps.
* Para información de horarios, calendarios y eventos de las distintas actividades, Google Calendar.

Explicar el porqué es bien fácil; antes de que termine el año tengo que presentar un proyecto para dar por concluida una etapa de dos años en la que centré mi vida en la realización de un Master en Ingeniería Web, en la Universidad de Oviedo.

Por motivos laborales, me pasé el verano de 2008 desarrollando un proyecto sobre un Gestor de contenidos para el Gobierno Vasco, así que digamos que partía de la base de que tenía unos conocimientos previos sobre el tema. Lo demás, fue casualidad. La profesora Lourdes Tajes ofertaba un proyecto sobre gestores de contenidos, me reuní con ella y acepté las condiciones que me propuso.

El proyecto trata de realizar un gestor de contenidos ligero para un AMPA.

La web actual del ampa es ésta. Es una web mantenida por una sola persona (mi tutora), totalmente estática y con un estilo nada uniforme. Tiene el grandísimo inconveniente de que es muy difícil de mantener y por ello necesita un trabajo muy constante.

Por ello se tratará de incorporar un gestor que facilite la tarea de administración de los contenidos a tratar en el gestor. El resultado se irá viendo reflejado en este blog.

En un principio me debatí en cuanto a qué implementación de JSF usar. Las dos potenciales candidatas eran, por una parte, MyFaces y, por otra, IceFaces
Ésta segunda, añade Ajax a los componente JSF, con lo cual, se logran componentes visuales muy bonitos, pero por contra la accesibilidad se verá limitada. La interfaz de usuario será casi lo más importante a tener en cuenta en este proyecto, por esto se optará por una implementación usando MyFaces.

Para ello, había varias alternativas de proyecto:

-proyecto 1.- Proyecto creado en MyEclipse.
Desde MyEclipse le pongo web project capabilities(java ee5)
Desde MyEclipse le pongo jsf capabilities.
Aquí hay dos problemas principales:
a)El proyecto web no se crea con Maven, con lo cual no sigue la jerarquía dictada por Maven ni tiene pom.xml
b)La implementación de jsf que se usa en este caso no es MyFaces, sino la proporcionada por Sun, que viene por defecto con Java EE 5.

-proyecto 2.- Proyecto creado en MyEclipse.
Desde MyEclipse le pongo web project capabilities(j2ee 1.4)
Desde eclipse le pongo jsf capabilities (myfaces)
Aquí, seguimos con el inconveniente de que el proyecto no se crea con Maven. No es una solución válida.

-proyecto 3.- Proyecto creado con Maven.
Desde MyEclipse le pongo web project capabilities(java ee5)
En el pom.xml le pongo las dependencias de MyFaces.
El problema aquí es que se chocan las dependencias de jsf provenientes de MyFaces y las que proporciona el propio Java EE 5. Por lo tanto, tampoco es una solución válida.

-PROYECTO 4.- Proyecto creado con Maven.
Desde MyEclipse le pongo web project capabilities(j2ee 1.4)
En el pom.xml le pongo las dependencias de MyFaces.
Ésta es la mejor solución encontrada hasta el momento, por tanto, será la elegida.

-proyecto 5.- Proyecto creado con Maven.
Desde MyEclipse le pongo web project capabilities (java ee 5)
Desde Myclipse le añado jsf capabilities (MyFaces).
La única mejora aquí con respecto al proyecto1, es que el proyecto se crea con la jerarquía de directorios que te proporciona Maven. No obstante, la implementación que se está usando sigue sin ser MyFaces, que es lo deseado.

-proyecto 6.- Proyecto creado con Maven.
Desde MyEclipse le pongo web project capabilities (j2ee 1.4)
Desde MyEclipse le pongo jsf capabilities (MyFaces).
Aquí se mejora con respecto al proyecto 2 en que la estructura se crea con Maven. No obstante, se da un paso atrás con respecto al proyecto 4 en cuanto le añades al proyecto todas las librerías dependientes de MyFaces (te las carga MyEclipse), por lo tanto el proyecto es más pesado.

Instalé Maven en mi equipo siguiendo este tutorial y este otro tutorial. Como tengo Windows Vista, tuve que tocar un fichero para modificar la ruta del repositorio local , puesto que en Vista no existe el directorio Documents and Settings…necesario para el repositorio local por defecto al instalar Maven (C:\Documents&Settings\usuario\.m2\repository)

Posteriormente instalé el plugin de Eclipse, MyEclipse, que utilizaré como IDE de desarrollo.

Hay dos formas básicas de integrar Maven con Eclipse:

-Por un lado podemos instalar en eclipse un plugin de Maven, de forma que desde Eclipse podamos ejecutar los comandos maven.

-Por otro lado, con un comando maven podemos crear un proyecto de eclipse. Luego desde eclipse importamos el proyecto y todo funciona. Seguimos usando eclipse como siempre. Ésta es la forma elegida. Tan sólo hay que declarar la variable de entorno M2_REPO desde Eclipse, para que Eclipse sepa dónde está tu repositorio Maven local (Window–>Preferences–>Java–>Build Path–>Classpath variables). OJO!! Esta variable ha de ser declarada para cada workspace que desee trabajar con Maven, puesto que las variables no se guardan entre workspaces distintos.

No obstante, la integración de Eclipse con Maven está mucho mejor explicada aquí.

Una vez que está todo el entorno configurado, ya podemos empezar a crear proyectos con Maven. Para crear un proyecto web,  basta situarnos en el directorio padre donde se creará y ejecutar el siguiente comando:

mvn archetype:create -DgroupId=groupId -DartifactId=artifactId
-DarchetypeArtifactId=maven-archetype-webapp

Donde groupId es el nombre del paquete para las clases y artifactId es el nombre del proyecto.

Se te crea un proyecto con una jerarquía de subdirectorios como la siguiente:

artifactId
├───pom.xml
└───src
    └───main
        ├───resources
        └───webapp
            ├───index.jsp
            └───WEB-INF
                └───web.xml

Una vez creada la jerarquía del proyecto, hay que “adaptarlo” a un proyecto Eclipse (crear los ficheros .classpath y .project). A la vez se hace un clean del proyecto, con el siguiente comando:

mvn eclipse:clean eclipse:eclipse

Se importa el proyecto desde el IDE.  Es muy importante que la vista sea MyEclipse Java Enterprise, sino habrá problemas durante el despliegue, ya que el Eclipse no se comporta igual dependiendo de la vista en la que estemos desarrollando.

Si ahora intentamos desplegar el proyecto desde el Tomcat que viene por defecto con Eclipse, no podremos, ya que aunque creado mediante el arquetipo maven de proyecto web, necesitamos dotarlo de propiedades web desde el Eclipse (esto es algo que no entiendo, pero es así y así hay que hacerlo para que funcione). Para ello, nos situamos sobre el proyecto con el botón derecho del ratón y hacemos MyEclipse–>Add Web Project capabilities, poniendo como Web Root Directory la carpeta webapp del proyecto. Ahora ya podemos desplegarlo en Tomcat y probar que funciona yendo al navegador

http://localhost:8080/artifactId, nos saldrá la página de inicio por defecto.