Lycka Bonita

Struts es un framework que ha triunfado por implementar el patrón que a la postre resultó el más adecuado para aplicaciones web, MVC, por su sencillez para desarrollar y mantener aplicaciones, facilidad de aprendizaje y modularidad. Esta modularidad es la que le ha permitido copar el mercado durante estos años después añadir piezas para completar el puzzle, como Struts Validator, Tiles, Log4J, SSLExt… Y a su vez le permitirá sobrevivir como una pieza dentro de otros frameworks más completos como Spring.

Struts no hace magia, cumple junto a sus extensiones con la mayoría de las necesidades de los desarrolladores, pero aún presenta ciertas "lagunas" como la seguridad. La razón es que cada organización es muy particular a la hora de definir e implementar ciertas funciones en general y sus políticas de seguridad en concreto.

Para estos casos, Struts permite implementar fácilmente estas nuevas necesidades, típicamente mediante la extensión / sobreescritura de sus clases y sus métodos. Pero OJO! tu aplicación ya no estará utilizando Struts sino tu propio framework, con sus ventajas (se supone que cumple al 100% con tus requisitos) e inconvenientes: sensibilidad de los cambios, mayor dificultad de mantener, de aprender, pruebas, documentación…

Pensar dos veces, actuar una

El hecho de que puedas hacer algo no significa que debas hacerlo o que sea bueno. La experiencia es vital antes de dar el siguiente paso. Implementar tu propio framework puede resolverte la vida o destruir una aplicación en pocas semanas. Antes de cualquier modificación, por mínima que sea, deberías de

1. Estar seguro al 100% de que el requisito a cumplir es necesario.
2. Estar seguro al 100% de que el requisito a cumplir seguirá siendo necesario durante el ciclo de vida de la aplicación, que ya conocemos a los clientes y donde dicen digo…
3. Estar seguro al 100% de que es la mejor forma de implementarlo.
4. Hacer comprender a tu cliente / jefe de que es un cambio especial. Traducido al lenguaje que pueda entender un cliente / jefe
1. Has informado por escrito y Necesitas autorización por escrito para continuar.
2. Necesitas tiempo para realizar un correcto análisis y diseño de esta solución y sus posibles alternativas.
3. Tardará más tiempo que un desarrollo normal porque son cambios más sensibles (afectan y afectarán a toda la aplicación)
4. Es altamente recomendable documentar este desarrollo
5. Es imprescindible realizar pruebas, eso que en España no sabemos lo que son…
5. Hazlo !!!

Estos pasos previos te llevarán una mañana, y en un futuro pueden ahorrarte semanas de trabajo. 

Para un cambio tan trillado y documentado como sobreescribir el processroles pues no montes tanto follón, o sí que así te das más caché delante del jefe