Lycka Bonita

A partir del comentario de Jesús (mil agradecimientos), por fin he sacado tiempo para escribir este artículo.

La motivación es simple.

Los frameworks nos simplifican la vida (eso dicen), pero el precio a pagar es mantener ficheros xml enormes y monolíticos (literalmente miles de líneas en cada fichero) para cada proyecto de nuestra organización. Recordando las motivaciones que llevaron al triunfo a la programación modular frente a la programación monolítica (simplicidad y reutilización), es posible también framentar los ficheros xml de configuración de nuestros frameworks, pasando de inmantenibles ficheros en varios ficheros pequeños.

Así es más fácil trabajar en organizaciones con muchos proyectos bajo una arquitectura: fomentando la reutilización de módulos, facilita el mantenimiento de la aplicación, el aprendizaje de los nuevos miembros del equipo, facilita y fomenta el trabajo en equipo… 

Esta fragmentación la podemos declarar de dos maneras:

1. Declarando una lista separando los nombres por comas
2. Utilizar comodines

Spring

En el fichero web.xml podemos configurar el framework de Spring utilizando varios ficheros.

<context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>
            /WEB-INF/spring/applicationContext-*.xml
      </param-value>
</context-param>

<context-param>

      <param-name>pathWebInf</param-name>
      <param-value>WEB-INF/</param-value>
      <description>WEB-INF</description>

</context-param>

<listener>
      <listener-class>
            org.springframework.web.context.ContextLoaderListener
      </listener-class>
</listener>

También hubiese sido correcto:

 <context-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>
            /WEB-INF/spring/applicationContext-ibatis.xml,
            /WEB-INF/spring/applicationContext-negocio.xml,
            /WEB-INF/spring/applicationContext-resources.xml,
            /WEB-INF/spring/applicationContext-struts.xml
      </param-value>

</context-param>

Struts

De manera análoga podemos fragmentar un fichero struts-config.xml en varios ficheros más manejables.

En este caso un humilde servidor recomienda la utilización de wildcards antes de realizar la fragmentación.

Si todavía piensas que este fichero necesita fragmentarse, entonces este humilde servidor recomienda revisar el análisis y el diseño de la aplicación, porque algo debe de estar fallando.

Y si todavía piensas que necesitas fragmentar este fichero, pues sí que es posible, de manera análoga a lo que hemos visto en Spring, declarando en el web.xml un listado de ficheros xml separados por comas o con el comodín.

Tiles

Podemos declarar una lista de ficheros XML separados por comas al configurar este plug-in en el struts-config.xml. Así podemos clasificar las tiles como nostros queramos, por pantallas (Acceso, FirmaElectronica, RegistroTelematico…), por tipos de tiles  (cabeceras, botoneras, menus…)

<plug-in className="org.apache.struts.tiles.TilesPlugin">

      <set-property property="definitions-config"

            value="/WEB-INF/tiles/tiles-defs.xml,
            /WEB-INF/tiles/tiles-Acceso.xml,
            /WEB-INF/tiles/tiles-FirmaElectronica.xml,
            /WEB-INF/tiles/tiles-RegistroTelematico.xml" />

      <set-property property="moduleAware" value="false" />

      <set-property property="definitions-parser-validate" value="false" />

</plug-in>

Struts Validator

Podemos declarar varios ficheros XML separados por comas en nuestro fichero struts-config.xml para configurar el framework. 

<plug-in className="org.apache.struts.validator.ValidatorPlugIn">

      <set-property property="pathnames"

            value="/WEB-INF/validator/validator-rules.xml,

/WEB-INF/validator/validator-rules-arquitectura.xml,                         /WEB-INF/validator/validator-rules-firmaelectronica.xml,

/WEB-INF/validator/validation.xml,

/WEB-INF/validator/validationAccesoForm.xml,
/WEB-INF/validator/validationSolicitudForm.xml" />

</plug-in>

El fichero validator-rules describe las reglas estándar que vienen con la distribución de Struts, validator-rules-arquitectura podría describir las reglas propias de arquitectura como las validaciones de NIF, NIE, CIF…, validator-rules-firmaelectronica las propias del proyecto particular en el que se trabaja. Además, validation podría describir las reglas globales, y luego podemos utilizar un fichero para validar cada formulario (validationAccesoForm y validationSolicitudForm).

No related posts.