Recientemente en una formación de modelización de contenidos de
Alfresco me preguntaron largo y tendido sobre las ventajas y miserias
de las denominadas constraint lists en Alfresco. Os dejo aquí algunas
de esas reflexiones.
En el diseño de tipos documentales en Alfresco es relativamente usual
utilizar combos de selección para los metadatos de los formularios en
Alfresco. Usualmente se utilizan constraints de tipo lista definidos
en los xml de modelo correspondiente. Las principales características
de una constraint de tipo lista son las siguientes:
- Son listas estáticas, es decir que las editamos en un XML de
definición del modelo y es necesario reiniciar el servidor Alfresco
para que los cambios tengan efecto, ya sea para añadir una o para
cambiar el nombre de uno de los valores de la lista. - Sólo los administradores de sistema pueden editarlas.
- Son internacionalizables desde la versión 4 de Alfresco.
- Son ordenables.
- No es posible extraerlas como una lista via API.
- El mapeo al metadato es el propio valor de texto, con lo que no es
recomendable cambiar el texto. Si es el caso, es necesario cambiar
todos los metadatos de ese tipo lista previamente consolidados en el repositorio.
Nota: No estamos considerando modelos dinámicos en Alfresco.
- https://wiki.alfresco.com/wiki/Content_Model_Constraints
- http://wiki.alfresco.com/wiki/Dynamic_Models
Se puede llegar a consumirlas de manera dinámica (sin tener que
reiniciar el servidor de Alfresco y sin recurrir a los modelos
dinámicos) desde implementaciones que permiten hacer querys a una base
de datos o directamente a una query de Lucene en el servidor, como
hemos comentado aquí en otras ocasiones.
Esta última basada en una query sobre el repositorio proporciona dos
variaciones interesantes.
- Si guardamos un conjunto de espacios por ejemplo en Data
Dictionary > Constrainsts Lists al que accedemos via query de
Lucene, hacemos que esas querys sean efectivamente dinámicas, y
además serían facilmente consumibles via API (a través de un
webscript que proporcione un listado de los valores posibles). El
punto fuerte de esta aproximación, es que con los permisos adecuados
un usuario no administrador de Alfresco, podría editarlas
directamente o añadir nuevas. De igual modo que en una constraint
list se guarda el valor, y no la referencia, y no son estrictamente
ordenables (el orden va a depender de la query).
- Si guardamos los valores en un conjunto de categorías y hacemos la
query de Lucene correspondiente, guardaremos los valores a través de
las referencias a las categorías y también serían facilmente
consumibles via API. Sin embargo, la gestión de las categorías se
realizaría a través de un administrador de Alfresco con acceso a la
consola de administración de categorías, y tampoco serían
internacionalizables ni estrictamente ordenables.
Esta aproximación via query de Lucene sobre espacios es similar a la
del módulo de gestión de listas en Alfresco Share.
http://addons.alfresco.com/addons/alfresco-listmanager
Estas listas de datos se gestionan en la consola de administración de
Alfresco Share de manera dinámica. Las características del módulo son
las siguientes:
- Son dinámicas y se pueden agregar en caliente. El valor guardado
en el metadato es también el valor de texto, con lo que no es
recomendable cambiar los nombres. Si es el caso, es necesario
cambiar todos los datos consolidados previamente con un script que
cambia el valor, al igual que en una constraint list. - Un usuario admin de Alfresco puede generarlas en la consola de
admin, incluso un usuario con los permisos adecuados. - Se gestionan mediante estructuras de carpetas en Alfresco, por
debajo de Diccionario de datos. - No son internacionalizables (en principio).
- Son ordenables.
- Se puede obtener un listado de ellas via API, a través de un webscript.
- Existen ciertas limitaciones en los nombres ya que son espacios
(por ejemplo si queremos poner una url).
Otra aproximación posible es utilizar únicamente categorías, en lugar
constraints basadas en queries de Lucene que consumen categorías. En
este caso, se utilizan los componentes de categorías en el modelo de
contenidos y en los componentes de Alfresco Share. En este caso:
- Un usuario admin de Alfresco puede generarlas en la consola de admin.
- No hay orden (alfabático unicamente si introduce un cierto
criterio en los literales de las categorías). - No son internacionalizables.
- Se pueden consumir directamente via webscript para obtener un listado.
- El mapeo al metadato es a través de una referencia, lo que implica
que puedes cambiar el valor sin problemas en la instancia. Esto sin
embargo es más problemático si se hace un traslado de estos datos o
copia de datos a otra instancia.
Esta última es también una posibilidad para asignar múltiples valores
en Alfresco Share.
