Contenidos personalizados en alfresco ecm

Alfresco ECM 4.2
Tipos de contenidos personalizados
Índice del capítulo
‣ Introducción.
‣ Diccionario de datos.
‣ Creación de un nuevo modelo de contenidos.
‣ Despliegue de modelo de contenidos.
‣ Configurar los clientes Web.
‣ Búsquedas en Alfresco.
‣ Custom Behaviors en Alfresco.
Preparado por Jesús Salinas Revelles

Introducción
‣ Alfresco trabaja con el concepto de MODELO DE CONTENIDOS para
gestionar de los contenidos que maneja.
‣ Alfresco incorpora un metamodelo en su estructura, es decir, la
capacidad para que nosotros declaremos nuevos modelos de
contenido.
‣ Un modelo de contenido define la estructura de información que
acompañará a nuestros documentos digitales.
‣ Esta definición nos permite dotar de semántica al documento para que
posteriormente se puedan implementar búsquedas y procesos más
eficientes e “inteligentes”.
Introducción
‣ Un modelo de contenidos es un conjunto de tipos de contenido y
aspectos. Los modelos de contenidos definidos son identificados de
forma unívoca mediante espacios de nombre (namespaces).

Introducción
‣ El modelo de contenidos por defecto se conoce en Alfresco como
Diccionario de Datos o Data Dictionary y soporta ser extendido para
que el repositorio pueda manejar nuevos modelos de contenido.
‣ El Diccionario de Datos describe las estructuras del contenido a través
de propiedades, asociaciones y reglas o restricciones.
‣ El Diccionario de Datos es un metamodelo que permite describir uno o
más modelos de contenido específicos.
Diccionario de datos
‣ Define dos clases de estructuras: tipos de contenido y aspectos de
contenido. Son conceptos que vamos a manejar de forma instensiva:
TIPO y ASPECTO.
‣ La diferencia entre Content Type y Content Aspect es que un contenido
sólo tiene un tipo que es el que define su estructura fundamental. Sin
embargo, un mismo contenido puede tener muchos aspectos que son
conceptos transversales aplicables a cualquier tipo de contenido.
‣ Un mismo nodo puede tener un aspecto en un momento temporal y
posteriormente dejar de tenerlo.

‣ El diccionario de datos define los siguientes modelos:
‣ System: describe conceptos a nivel del repositorio. http://www.alfresco.org/model/
system/1.0. Prefijo sys.
‣ Content: describe el modelo de contenido del dominio estándar (ej. Carpeta,
Fichero, Dublin-Core, ...). http://www.alfresco.org/model/content/1.0. Prefijo cm.
‣ Application: describe el modelo de aplicación de Alfresco (ej. glosario, ...). http://
www.alfresco.org/model/application/1.0. Prefijo app.
‣ Dictionary: describe el metamodelo del Diccionario de Datos (enteros, flotantes,
fechas...). http://www.alfresco.org/model/dictionary/1.0. Prefijo d.

‣ El diccionario define un conjunto de tipos de datos soportados por
defecto, es decir, vamos a poder manejar textos, números, fechas,
booleanos, etc, sin necesidad de tener que definir nuevos tipos:
‣ Los tipos de dato content, folder y person se encuentra en el modelo
Content, es por eso que al referenciarlos se utiliza cm:content,
cm:folder y cm:person.
‣ Los tipos de dato int, boolean, double y date se encuentra en el modelo
Dictionary, es por eso que al referenciarlos se utiliza d:int, d:boolean,
d:double y d:date.
‣ Todos los detalles en la wiki de Alfresco:
‣ http://wiki.alfresco.com/wiki/Data_Dictionary_Guide.

‣ Alfresco almacena, por defecto, los documentos como nodos de tipo
cm:content que están formados por un fichero binario y por los
metadatos básicos (titulo, autor, fecha de modificación, etc.)
‣ Podemos heredar de cm:content para hacer un nuevo tipo “Informe
Técnico”.
NODO DE ALFRESCO DE TIPO "INFORME TÉCNICO"
INFORME TÉCNICO
INFORMACIÓN ESTRUCTURADA
MANEJADA POR EL GESTOR DOCUMENTAL
Número de informe : INF000XXX
Título : XXXXX
Autor : XXXXXXX
Etiquetas o palabras clave: XXX , YYY, ZZZ
Responsables: <Lista de usuarios del sistema o lista de
nombres>
Proceso: XXXX
<<CUALQUIER OTRO METADATO QUE QUIERA
DEFINIR EL CLIENTE>>
InformeTecnico.doc
‣ Los tipos presentan un gran parecido a las clases en el mundo de
orientación a objetos.
‣ Un modelo de contenidos puede definir N tipos de contenido nuevos.
‣ Pueden usarse para representar objetos de nuestro modelo de
negocio: Tienen propiedades y pueden heredar de un tipo base.
Contenido (cm:content) , Persona (cm:person) o Carpeta (cm:folder)
son tres tipos importantes definidos por Alfresco.
‣ Los tipos personalizados están limitados únicamente por nuestra
imaginación y requerimientos de negocio.
‣ Factura, Receta médica o Película serían ejemplos de tipos personalizados.

Creación de un nuevo modelo de contenidos
‣ Paso 1: Declarar un nuevo modelo y definir los tipos de contenido
personalizado.
‣ Paso 2: Desplegar el nuevo modelo de contenidos
‣ Paso 3: Configurar el/los cliente(s) Web para que sea capaz de
reconocer los nuevos tipos de contenido.
‣ Paso 4: Reiniciar Alfresco para que los cambios sean efectivos. (en
caso de que sea necesario).
Declarar un nuevo modelo y definir los tipos de
contenido personalizado
‣ Crear un nuevo modelo.
‣ Declarar un nuevo modelo.
‣ Declarar el espacio de nombres para el modelo.
‣ Declarar un nuevo tipo de contenido.
‣ Asociaciones.
‣ Restricciones.
‣ Aspectos.

Crear un nuevo modelo
‣ Se declara en un fichero XML cuyo nodo principal es el elemento
<model> del esquema “Data Dictionary XML Schema”. Dicho esquema
está en el espacio de nombres referenciado por la URI
http://www.alfresco.org/model/dictionary/1.0
‣ Este fichero debe colocarse en la carpeta de extensión de Alfresco para
despliegues estáticos y dentro del espacio “Company Home -> Data
Dictionary -> Models”) para despliegues dinámicos.
Declarar un nuevo modelo
<model name="prefijo:nuevoModelo"
xmlns="http://www.alfresco.org/model/dictionary/1.0">
<description>Modelo Contenido Nuevo</description>
<author>Formacion S.L.</author>
<published>2011-01-01</published>
<version>1.0</version>
<imports>

<import uri="http://www.alfresco.org/model/dictionary/1.0" prefix="d"/>

<import uri="http://www.alfresco.org/model/content/1.0" prefix="cm"/>
</imports>
...

‣ El atributo name del elemento model define el nombre único del
modelo. El prefijo debe usarse el que se declare en el espacio de
nombres (ver siguiente transparencia).
‣ xmlns declara el espacio de nombres del metamodelo como espacio
de nombres por defecto.
‣ La sección de imports hace que los modelos de contenido estándares
así como el metamodelo y el diccionario de datos estén disponible
para su uso y referencia en nuestro modelo.
‣ Se define el espacio de nombres asociado al nuevo modelo:
...

<namespaces>
<namespace
uri="http://www.formacion.com/xmlns/modelo/1.0/"
prefix="prefijo"/>
</namespaces>
...
‣ uri: identificador único del espacio de nombres
‣ prefix: prefijo que se usará en el resto del documento (debe coincidir también con el
que usa el modelo en la transparencia anterior).

Declarar un nuevo tipo de contenido
‣ Los nuevos tipos de contenido se declaran dentro del modelo:
<model ... >
...
<types>
<type ...>
...
</type>
</types>
</model>
‣ Generalmente querremos heredar de cm:content que es el tipo de
contenido estándar de Alfresco.
‣ cm es el prefijo del espacio de nombres http://www.alfresco.org/
model/content/1.0 definido para el esquema Content Domain Model.
‣ Veamos un ejemplo: declarar un tipo de contenido “Documento de
Agencia Tributaria” que tenga las propiedades (metadatos)
“MailResponsable”, “Proyecto”, “EstaAprobadoPorDireccion”.
Tipo de contenido : Documento de Agencia Tributaria
<types>
<type name="aeat:documento">
<title>Documento de Agencia Tributaria</title>
<parent>cm:content</parent>
<properties>
<property name="aeat:MailResponsable">
<title>eMail del responsable del documento</title>
<type>d:text</type>
</property>
<property name="aeat:Proyecto">
<title>Proyecto al que pertenece</title>
<type>d:text</type>
</property>
<property name="aeat:EstaAprobadoPorDireccion">
<title>Aprobado por direccion</title>
<type>d:boolean</type>
</property>
</properties>
</type>
</types>

Declaración básica de propiedades
‣ La declaración básica de una propiedad (metadato) de un tipo de
contenido es :
...
<type ... >
<property name="prefijo:nombrePropiedad">
<title>Titulo del metadato</title>
<type>d:tipoDeDato</type>
</property>
...
</type>
...
Tipo de dato declarado por el Data
Dictionary de Alfresco
Tipos de datos para las propiedades
‣ Como ya hemos comentado antes, los tipos de datos soportados en el
esquema Dictionary son:

Opciones avanzadas de las propiedades
‣ Elemento mandatory:
‣ El cliente Web de Alfresco obliga a completar todas las propiedades mandatory.
‣ El repositorio de Alfresco obliga a completar todas las propiedades cuya propiedad
enforced del elemento mandatory esté a cierta.
<mandatory enforced='true|false'>true|false</mandatory>
‣ Ejemplo:
<title>Titulo del metadato</title>
<type>d:tipoDeDato</type>
<mandatory enforced='true'>true</mandatory>
</property>
Opciones avanzadas de las propiedades
‣ Valores por defecto: como su nombre indica, podemos asignar un valor
por defecto a cualquier propiedad definida:
...
<default>{valor}</default>
</property>
‣ Ejemplo:
...
<property name="vodafone:tipoFormacion">
...
<default>presencial</default>
</property>
...

Asociaciones
‣ Las asociaciones permiten definir punteros a otros contenidos, es
decir, relaciones entre diferentes tipos de contenidos.
‣ Por ejemplo, permitiría a un documento “Resumen anual de gastos”
hacer referencia a varios “Resúmenes mensuales de gastos”.
‣ Alfresco trabaja con dos tipos de asociaciones:
‣ Child Associations: Asociación que funciona como un “cascade delete” en base de
datos relacional, es decir, el hijo sólo existe si existe el padre (agregado en UML).
‣ Peer Asociations: Asociaciones simples.
Asociaciones
‣ El elemento associations define todas las asociaciones definidas para
un tipo o aspeccto.
‣ Sintaxis:
...
...
<associations>
<child-association >
</child-association>
<association>
...
</association>
</associations>
...

Asociaciones
‣ Cualquier asociación define dos extremos: en Alfresco los llamaremos
source y target.
‣ Se define una cardinalidad: 1 a n, n a n, 1 a 1, etc.
‣ ¿Cómo definimos este concepto a la hora de crear la asociación?
Entidad 1 asociación
Entidad 2
Asociaciones
‣ El elemento source define el origen de la asociación: mandatory indica
si la existencia de este elemento es obligatoria y many si puede existir
más de uno:
<source>
<mandatory>false</mandatory>
<many>false</many>
</source>
‣ El elemento target define el otro extremo de la asociación: el elemento
class define el tipo de dato.
<target>
<class>sys:base</class>
<many>true</many>
</target>

Child Associations
‣ Las operaciones de tipo child son algo especiales. La entidad padre es
dueña de los hijos, es decir, las operaciones como el borrado se
propagan a los hijos.
‣ Ejemplo:
<child-association name="cm:contains">
<source>
<many>false</many>
</source>
<target>
<many>true</many>
</target>
<duplicate>false</duplicate>
Child Associations
‣ Este tipo de asociaciones son fácilmente navegables usando
Alfresco's XPath y los lenguajes de búsqueda de Lucene.

Child Associations
‣ Ejemplo: Carpeta <-> Contenido
<type name="cm:folder">
<title>Folder</title>
<parent>cm:cmobject</parent>
<associations>
<child-association name="cm:contains">
<source>
<many>false</many>
</source>
<target>
<many>true</many>
</target>
<duplicate>false</duplicate>
</associations>
</type>
Non-Child Associations
‣ Las operaciones como el borrado NO se propagan a los hijos.
‣ Los lenguajes de búsqueda de Alfresco NO soportan la navegación de
este tipo de asociaciones.
‣ El elemento association define este tipo de asociaciones.
‣ Su sintaxis es muy similar a la definida anteriormente: source y target.

Non-Child Associations
<aspect name="cm:subscribable">
<associations>
<association name="cm:subscribedBy">
<source>
<many>true</many>
</source>
<target>
<class>cm:person</class>
<many>true</many>
</target>
</association>
</associations>
</aspect>
Ejemplo
‣ Si queremos que cualquier nodo forme parte de una asociación:
...
<target>
</target>
...

Restricciones
‣ Introducción.
‣ Tipos de restricciones.
‣ Definición de restricciones.
‣ Uso de restricciones.
Introducción
‣ El concepto de restricción puede utilizarse opcionalmente para
restringir los valores que Alfresco almacenará en nuestras
propiedades.
‣ Están definidas 4 tipos de restricciones: REGEX, LIST, MINMAX y
LENGTH.
‣ Las restricciones se definen una única vez y se reutilizan en todo el
modelo.
‣ Alfresco incorpora una restricción predefinida “cm:filename” que
define una expresión regular para chequear que una cadena es un
nombre de fichero válido.

Introducción
‣ Las restricciones se incluyen dentro del modelo de contenidos
mediante los elementos xml constraints y constraint:
<model name="test:dictionarydaotest" xmlns="http://
www.alfresco.org/model/dictionary/1.0">
<imports> ... </imports>
<namespaces> ... </namespaces>
<data-types>
...
</data-types>
<constraints>
...
</constraints>
</model>
Tipos de restricciones
‣ Restricción REGEX: esta restricción nos permite restringir el valor de
una propiedad mediante una expresión regular.
‣ Debemos definir dos parámetros:
‣ expression: la expresión regular.
‣ requiresMatch: booleano que define si se requiere coincidencia o NO coincidencia.
‣ Restricción LIST: esta restricción nos permite restringir el valor de una
propiedad mediante una lista de valores.
‣ allowedValues: lista de valores permitidos.
‣ caseSensitive: booleano que define si tenemos en cuenta mayúscula y minúscula.

Tipos de restricciones
‣ Restricción MINMAX: esta restricción nos permite restringir el valor de
una propiedad mediante rango de valores.
‣ minValue: valor mínimo.
‣ maxValue: valor máximo.
‣ Restricción LENGTH: esta restricción nos permite restringir la longitud
una propiedad de tipo cadena.
‣ minLength: longitud mínima.
‣ maxLength: longitud máxima.
Definición de restricciones
‣ El elemento constraint permite definir una restricción.
‣ Sintaxis:
<constraint name="prefix:nombreRest" type="tipoDeRest">
<parameter ...> </parameter>
</constraint>
‣ Los atributos name y type definen el nombre de la restricción y el tipo.
‣ Los elementos parameter nos permitirán parametrizar cada tipo de
restricción.

‣ Ejemplo de REGEX:
‣ Cadenas que no contengan letras mayúsculas.
<constraint name="test:regex1" type="REGEX">
<parameter name="expression">
<value>[A-Z]*</value>
</parameter>
<parameter name="requiresMatch">
<value>false</value>
</parameter>
</constraint>
‣ Ejemplo de REGEX:
‣ Cadenas que no contengan letras minúsculas.
<constraint name="test:regex2" type="REGEX">
<parameter name="expression">
<value>[a-z]*</value>
</parameter>
<parameter name="requiresMatch">
<value>false</value>
</parameter>
</constraint>

‣ Ejemplo:
‣ Cadenas con longitud comprendida entre 0 y 256.
<constraint name="test:stringLength1" type="LENGTH">
<parameter name="minLength">
<value>0</value>
</parameter>
<parameter name="maxLength">
<value>256</value>
</parameter>
</constraint>
‣ Ejemplo:
‣ Valores comprendidos entre 0 y 256.
<constraint name="test:minMax1" type="MINMAX">
<parameter name="minValue">
<value>0</value>
</parameter>
<parameter name="maxValue">
<value>256</value>
</parameter>
</constraint>

‣ Ejemplo:
‣ Cadenas que sean “ABC” o “DEF” sensible a mayúsculas.
<constraint name="test:list1" type="LIST">
<parameter name="allowedValues">
<list>
<value>ABC</value>
<value>DEF</value>
</list>
</parameter>
<parameter name="caseSensitive">
<value>true</value>
</parameter>
</constraint>
Uso de restricciones
‣ El elemento constraints hijo de property nos permite aplicar
restricciones sobre cualquier propiedad.
‣ Dentro del elemento constraints se pueden añadir tantas restricciones
como sean necesarias mediante constraint:
<property name="prefix:nombrePropiedad">
...
<constraints>
<constraint ref="prefix:nombreRestriccion"/>
...
</constraints>
</property>
‣ El atributo ref determina el nombre de la restricción a aplicar.

Uso de restricciones
‣ Ejemplo:
<property name="test:prop1">
<type>d:text</type>
<protected>true</protected>
<constraints>
<constraint ref="test:regex1"/>
<constraint ref="test:stringLength1"/>
</constraints>
</property>
¡Cuidado con las restricciones!
‣ IMPORTANTE:
‣ ¡El orden en los ficheros de definición de nuevos modelos importa!.
‣ Primero debe declararse la restricción y luego hacerle referencia. Si lo hacemos al
contrario se producirá un error grave y Alfresco no se inicializará.

Aspectos
‣ Introducción.
‣ Definición de aspecto.
‣ Aspectos por defecto.
Introducción
‣ Los aspectos nos permiten aplicar conceptos transversales
(propiedades o asociaciones) a cualquier pieza de contenido (sea cual
sea su tipo) y en cualquier lugar.
‣ Son fundamentales a la hora de diseñar buenos modelos reutilizables,
flexibles y con buen rendimiento.
‣ Se pueden aplicar a un nodo y posteriormente quitarle estas
propiedades. Son de “quita y pon”.

Definición de aspecto
‣ El elemento aspect define un aspecto dentro del modelo de
contenidos.
<aspect name="prefix:aspectName">
<title>aspectTitle</title>
<properties>
<property >
...
</property>
...
</aspect>
‣ Se define de forma similar a un tipo de contenido.
Definición de aspecto
‣ Ejemplo:
<aspect name="cm:auditable">
<title>Auditable</title>
<properties>
<property name="cm:created">
<type>d:datetime</type>
</property>
<property name="cm:creator">
<type>d:text</type>
</property>
<property name="cm:modified">
</property>
...
</properties>
</aspect>

Aspectos por defecto
‣ Alfresco nos ofrece un conjunto de aspectos, por defecto, que
podemos utilizar en nuestros modelos de contenidos:
‣ Classifiable Aspect: activa la categorización, por lo tanto se puede aplicar
categorías sobre el documento.
‣ Complianceable Aspect: se añade la propiedad para indicar cuándo debe borrarse.
‣ Dublin Core Aspect: añade los metadatos de Dublic Core: publisher, Contributor,
Subject y Rights.
‣ Effectivity Aspect: añade las propiedades From y To al documento.
‣ Emailed Aspect: añade un conjunto de propiedades de Email Data al documento.
‣ Localizable Aspect: añade la propiedad Locale to the document.
‣ Summarizable Aspect: añade la propiedad Summary al documento.
‣ Templatable Aspect: añade la propiedad cm:template, que es la referencia a otro
nodo, que será la plantilla.
‣ Translatable Aspect: añade la propiedad Translations al documento.
‣ Versionable Aspect: habilita el versionado de documentos.

‣ Classifiable Aspect:
<aspect name="cm:classifiable"><title>Classifiable</title></aspect>
<aspect name="cm:generalclassifiable">
<title>General Classifiable</title>
<parent>cm:classifiable</parent>
<properties>
<property name="cm:categories">
<title>Categories</title>
<type>d:category</type>
<multiple>true</multiple>
<index enabled="true">
<atomic>true</atomic>
<stored>true</stored>
<tokenised>false</tokenised>
</index>
</property>
</properties>
</aspect>
‣ Complianceable Aspect:
<aspect name="cm:complianceable">
<title>Complianceable</title>
<properties>
<property name="cm:removeAfter">
<title>Remove After</title>
</property>
</properties>
<mandatory-aspects>
<aspect>cm:auditable</aspect>
</mandatory-aspects>
</aspect>

‣ Dublin Core Aspect:
<aspect name="cm:dublincore">
<title>Dublin Core</title>
<parent>cm:titled</parent>
<properties>
<property name="cm:publisher">
<title>Publisher</title>
<type>d:text</type>
<mandatory enforced="false">true</mandatory>
</property>
...
<mandatory-aspects>
<aspect>cm:auditable</aspect>
<aspect>cm:author</aspect>
</mandatory-aspects>
</aspect>
‣ Effectivity Aspect:
<aspect name="cm:effectivity">
<title>Effectivity</title>
<properties>
<property name="cm:from">
<title>Effective From</title>
...
</property>
<property name="cm:to">
<title>Effective To</title>
...
</property>
</properties>
</aspect>

‣ Translatable Aspect:
<aspect name="cm:translatable">
<title>Translatable</title>
<parent>cm:localizable</parent>
<associations>
<association name="cm:translations"><title>Translations</title>
<source><role>cm:translationOf</role>
<many>false</many>
</source>
<target><class>cm:content</class>
<role>cm:hasTranslation</role>
<many>true</many>
</target>
</association>
</associations>
</aspect>
Despliegue de modelo de contenidos
‣ Introducción.
‣ Crear el fichero de contexto.
‣ Despliegue estático.
‣ Despliegue dinámico.

Introducción
‣ Una vez que el modelo de contenidos ha sido definido, es decir, el
fichero xml ha sido creado, tenemos que desplegarlo en nuestra
instalación de Alfresco.
‣ Para que Alfresco reconozca la definición de nuestro nuevo modelo
debemos crear un fichero de contexto que haga de cargador de la
definición.
‣ El fichero de contexto debe llamarse como <nombreModelo>-
context.xml y colocarse en el fichero de extensión para que Alfresco lo
localice automáticamente.
‣ Los modelos pueden instalarse en Alfresco de forma estática o
dinámica. La primera necesitará el reinicio del sistema.
Crear el fichero de contexto
‣ El fichero de contexto contiene uno o más bean de configuración de
Spring.
‣ Dependiendo de la distribución de Alfresco que hayamos descargado
tendremos un conjunto de ficheros de contexto de ejemplo en el
directorio de extensión que nos servirán como plantilla para los
nuestros.
‣ Nota: el directorio de extensión es ${alfresco}/tomcat/shared/classes.

‣ Para la versión 4.2.c, la plantilla custom-model-context.xml.sample es:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://
www.springframework.org/dtd/spring-beans.dtd'>
<beans>

<bean id="extension.dictionaryBootstrap" parent="dictionaryModelBootstrap"
depends-on="dictionaryBootstrap">
<property name="models">
<list>
<value>alfresco/extension/customModel.xml</value>
</list>
</property>
</bean>
</beans>
‣ La ruta alfresco/extension/customModel.xml se define en relación a la
carpeta de extensión de alfresco.
‣ Resumiendo, si nuestro modelo se ha definido en un fichero llamado
companyModel.xml, el fichero de contexto se llamará companyModel-context.
xml
...
<beans>

<bean id="extension.dictionaryBootstrap" parent="dictionaryModelBootstrap"
depends-on="dictionaryBootstrap">
<property name="models">
<list>
<value>alfresco/extension/companyModel.xml</value>
</list>
</property>
</bean>
</beans>

Despliegue estático (Static model)
‣ El despliegue estático obligatoriamente implica un reinicio del sistema
para que los nuevos modelos de contenidos sean tenidos en cuenta.
Este despliegue implica:
‣ Copiar el fichero de contexto en la carpeta ${alfresco}/tomcat/shared/classes/
alfresco/extension.
‣ Copiar el fichero del modelo de contenidos en la carpeta ${alfresco}/tomcat/
shared/classes/<rutaDefinidaFicheroContexto>
‣ Reiniciar Alfresco.
Despliegue dinámico (Dynamic Model)
‣ Con el método anterior (modelos estáticos) será necesario reiniciar el
sistema para que lea los cambios de la carpeta de extensión.
‣ Existe la posibilidad de usar modelos dinámicos, que no requieren
parada del servicio.
‣ Para ello, debemos subir el fichero con nuestro nuevo modelo (el XML
que lo define, NO el que termina en -context.xml) al espacio “Company
Home -> Data Dictionary -> Models”.
‣ Cuando hagamos el upload del modelo al espacio previamente
mencionado, nos saldrá un check-box 'Model Active' que debemos
seleccionar si queremos desplegarlo.

Configurar los clientes Web
‣ Introducción.
‣ Personalizaciones Alfresco Explorer.
‣ Personalizaciones Alfresco Share.
Introducción
‣ Generalmente queremos que los clientes Web Alfresco Explorer y
Alfresco Share reconozcan el nuevo tipo de contenido para poder
gestionar instancias de él.
‣ En el directorio de extensión se encuentra el fichero web-client-config-custom.
xml [es posible que haya que renombrarlo porque aparezca
con extensión .sample] con el que podemos definir el comportamiento
de Alfresco Explorer.
‣ En el directorio web-extensión se encuentra el fichero share-config-custom.
xml [es posible que haya que renombrarlo porque aparezca
con extensión .sample] con el que podemos definir el comportamiento
de Alfresco Share.

Introducción
‣ Si queremos trabajar con modelos estáticos, se dejará el web-client-config-
custom.xml en la carpeta de extensión.
‣ Si queremos trabajar con modelos dinámicos (no necesario reiniciar),
entonces lo llevaremos al espacio Company Home -> Data Dictionary -
> Web Client Extension.
Personalizaciones Alfresco Explorer
‣ Para configurar personalizaciones en Alfresco Explorer vamos a añadir
un conjunto de claves de configuración que añadimos al web-client-config-
custom.xml.
‣ Las claves de configuración las debe “entender” la aplicación “Alfresco
Explorer” por lo que deberán seguir un conjunto estricto de convenios
que están especificados en la documentación de Alfresco y en las
siguientes transparencias.

‣ Property Sheet : Cuando un usuario observa las propiedades de una
pieza de contenido de un tipo personalizado, debemos mostrar las
propiedades personalizadas.
Drawing 2: Custom properties on the
properties sheet
!"#$%"&'(!"()"*#
add properties to property sheets use the “aspect-name” evaluator for aspects and “node-type” for
content types. The snippet below shows the config for the sc:webable aspect. The sc:productRelated
aspect would be similar.
Personalizaciones de la interfaz de usuario del WC

<config evaluator="aspect-name" condition="sc:webable">
<property-sheet>
‣ Para ello utiliza el evaluador “node-type” para tipos de contenido o
“aspect-name” para aspectos:
<config evaluator="node-type"
<show-property name="sc:published" display-label-id="published"
<show-property name="sc:isActive" display-label-id="isActive"
read-only="true" />
<show-association name=”sc:relatedDocuments” />
</property-sheet>
</config>
Listing 4: Snippet from web-client-config-custom.xml
the display-label-id attribute. You could specify the label in this file by using the label attribute,
better practice is to externalize the string so the interface could be localized if needed. At the end
this section we'll see where the localized strings reside.
Create content/Add content
a user clicks Create or Add Content, the custom types should be a choice in the list of content
as shown below:
condition="prefijo:nombreTipo">
<property-sheet>
<show-property name="prefijo:Propiedad1"/>
</property-sheet>
</config>

‣ Para ello utiliza el evaluador “node-type” para tipos de contenido o
“aspect-name” para aspectos:
<config evaluator="node-type"
condition="prefijo:nombreTipo">
<property-sheet>
</property-sheet>
</config>
¡HAY UNA CLAVE DE CONFIGURACION
DE ESTE TIPO en el web-client-config-custom.
xml POR CADA TIPO DE
CONTENIDO del modelo
Hay una entrada de tipo show-property por
cada propiedad específica del tipo que
queremos mostrar en los formularios
Hay que hacerlo coincidir con el nombre
de un tipo que pusimos en el modelo de
contenidos y con el prefijo que
declaramos en su espacio de nombres.
Sólo puede ser “node-type” o
“aspect-name”
‣ Ejemplos:
<config evaluator="node-type" condition="my:sop">
<property-sheet>
<show-property name="mimetype"
display-label-id="content_type"
component-generator="MimeTypeSelectorGenerator" />
<show-property name="size" display-label-id="size"
converter="org.alfresco.faces.ByteSizeConverter"
show-in-edit-mode="false" />
<show-property name="my:publishedDate" />
<show-association name="my:signOff" />
<show-property name="my:authorisedBy" />
<show-child-association name="my:processSteps" />
</property-sheet>
</config>

‣ Elemento show-property, atributos interesantes:
‣ name: nombre de la propiedad a mostrar.
‣ display-label-id: identificador de la etiqueta asociada a la propiedad.
‣ show-in-edit-mode: booleano que identifica si la propiedad aparece en modo edit o
no.
‣ converter: proceso de coversión a aplicar.
‣ Create content/add content: los tipos personalizados de contenido
deben ser una opción de la lista de selección de tipos.!"#$%"&'(!"()"*#
Drawing 3: Custom type in the add content
dialog
To add content types to the list of available types in the create content and add content dialogs, use the
string-compare” evaluator and the “Content Wizards” condition.

‣ Usamos el evaluador “stringcompare”
y la condición “Content
Wizards”.
<config evaluator="stringcompare"
condition="Content Wizards">
<contenttypes>
<type name="prefijo:nombreNuevoTipo" />
<type name="prefijo:nombreNuevoTipo2" />
</contenttypes>
</config>
‣ Usamos use el evaluador “stringcompare”
Wizards”.
<contenttypes>
</contenttypes>
</config>
No se cambia!

‣ Usamos use el evaluador “stringcompare”
Wizards”.
<!add
someco types to add content list >
<contenttypes>
</contenttypes>
</config>
¡No se
cambia!
¡No se
cambia!
Hay que hacerlos coincidir con los
nombres de los tipos que pusimos en el
modelo de contenidos y con el prefijo
que declaramos en su espacio de
nombres.
¡SOLO HAY UNA CLAVE DE
CONFIGURACION DE ESTE TIPO
en el web-client-config.xml!
‣ Para espacios personalizados, si queremos que nos aparezca un
nuevo tipo de espacio en el asistente de creación de espacio, debemos
incluir:
<config evaluator="string-compare"
condition="Space Wizards">
<folder-types>
<type name="prefijo:nombreTipo"/>
</folder-types>
</config>

‣ Si queremos que el nuevo tipo aparezca como opción de tipo de
contenido en el wizard de reglas de contenido, deberemos incluir lo
siguiente:
condition="Action Wizards">
<subtypes>
</subtypes>
</config>
‣ Para espacios personalizados, si queremos tener la posibilidad de
convertir los espacios existentes tendremos que añadir lo siguiente:
condition="Action Wizards">
<specialize-types>
</specialize-types>
</config>

Personalizar Alfresco Share
‣ Introducción.
‣ Nuevos tipos y aspectos.
‣ Configuración de formularios.
‣ Formulario de búsqueda avanzada.
Introducción
‣ El diseño de nuevos modelos de datos en Alfresco es una operación
muy habitual. Una vez diseñado dicho modelo podemos crear código
que trabaje directamente contra él.
‣ Ahora bien, para trabajar con el cliente web Alfresco Share, deberemos
introducir alguna modificación.
‣ El fichero donde se introducen dichas modificaciones es share-config-custom.
xml que será creado en ${tomcat_home}/shared/classes/web-extension.

Introducción
‣ ¿Dónde manejamos tipos de datos dentro de Alfresco Share?
‣ Cuando un usuario configura una regla sobre un aspecto y usa un tipo de
contenido como criterio.
‣ Cuando un usuario configura una regla sobre un espacio y usa un aspecto como
criterio.
‣ Cuando un usuario ejecuta una acción “specialize type”, como parte de una regla
de configuración o como una acción UI “Change Type” UI action, los tipos
personalizados deben aparecer.
‣ Cuando un usuario decide ejecutar Añadir Aspecto.
‣ Cuando el usuario analiza el detalle de un documento.
‣ Cuando el usuario edita los detalles de un documento.
‣ Cuando el usuario realiza búsquedas avanzadas.
Nuevos tipos y aspectos
‣ Informar a Alfresco Share de que existen nuevos tipos, aspectos, etc.
Las modificaciones se incluyen dentro del siguiente elemento:
<alfresco-config>
...

condition="DocumentLibrary">
...
</config>
...
</alfresco-config>

‣ Añadiendo aspectos:
...
<aspects>
<visible>
<aspect name="sc:webable" />
<aspect name="sc:productRelated" />
</visible>
<addable>
</addable>
<removeable>
</removeable>
</aspects>
...
‣ Añadiendo tipos:
...
<types>
<type name="cm:content">
<subtype name="sc:doc" />
<subtype name="sc:whitepaper" />
</type>
<type name="sc:doc">
<subtype name="sc:whitepaper" />
</type>
</types>
...

‣ Estas entradas xml type y subtype permiten definir el concepto de
herencia.
‣ El mismo tipo puede aparecer varias veces en la lista. Una vez cómo
subtipo de cm:content y otra como subtipo de sc:doc. Esto permite al
usuario especializar directamente el tipo sc:whitepaper
independientemente de si el original era cm:content o sc:doc.
‣ Se reinicia Tomcat y vemos los cambios.
‣ Reglas de contenidos:

‣ Cambiando el tipo de un nodo:
Configuración de formularios
‣ Alfresco Share utiliza el servicio de formularios para decidir qué
propiedades mostrar en cada caso.
‣ El evaluador node-type permite definir los formularios.
‣ Los nodos dentro de Alfresco Share se gestionan en formularios de
diferentes formas:
‣ View, Edit, Edit online.

‣ Sintaxis:
<config evaluator="node-type" condition="type">
<forms>
<form [id="string"] [submission-url="url"]>
<view-form template="path" />
<edit-form template="path" />
<create-form template="path" />
<field-visibility>
...
</field-visibility>
<appearance>
...
</appearance>
</form>
</forms>
</config>
‣ Los tres formularios son:
‣ Formulario por defecto (elemento form sin atributo id). Formulario cuando se abre
los detalles de un documento.
‣ Formulario con id doclib-simple-metadata. Formulario de edición de propiedades
desde la biblioteca de documentos.
‣ Formulario con id doclib-inline-edit. Este se utiliza cuando se accede a la edición
Inline.

‣ Cada formulario debe incluirse dentro de esta configuración:
<config evaluator="node-type" condition="sc:whitepaper">
<forms>
<form>
...
</form>
</forms>
</config>
‣ Formulario de edición:
<form id="doclib-simple-metadata">
...
</form>
‣ Formulario de edición online:
<form id="doclib-inline-edit">
...
</form>

‣ Ejemplo:
<form id="doclib-inline-edit">
<field-visibility>
<show id="cm:name" />
...
</field-visibility>
...
‣ Los elementos view-form, edit-form, create-form: permiten definir
plantillas personalizadas para los formularios de creación, edición y
visualización.
‣ Ejemplo:
<config evaluator="node-type" condition="cm:content">
<forms>
<form>
<create-form template="/path/to/custom/form1.ftl" />
</form>
</forms>
</config>
‣ El atributo template define la ruta donde se encuentra la plantilla.

‣ Elementos field-visibility y appearance:
...
<form>
<field-visibility>
<show id="sc:published" />
<show id="sc:isActive" />
</field-visibility>
<appearance>
<field id="sc:published"
label-id="prop.sc_published" />
<field id="sc:isActive" label-id="prop.sc_isActive"/>
</appearance>
</form>
...
‣ El elemento field-visibility se encarga de definir la visibilidad de los
campos asociados al tipo de dato que se van a mostrar en el
formulario.
‣ Si este elemento no existe todos los campos del tipo de dato son
visibles en todos los modos.
‣ Ejemplo:
<config evaluator="node-type" condition="sc:whitepaper">
<forms>
<form>
<field-visibility>
<show id="cm:title" force="true" />
<show id="cm:creator" for-mode="view" />
<show id="cm:taggable" for-mode="edit"
force="true" />

‣ Sintaxis field-visibility:
<config evaluator="node-type" condition="type">
<forms>
<form [id="string"] [submission-url="url"]>
...
<field-visibility>
<show id="string" [for-mode="view|edit|create"]
[force="boolean"] />
<hide id="string" [for-mode="view|edit|create"] />
</field-visibility>
...
</form>
</forms>
</config>
‣ Elemento show: especifica si un campo aparece en un formulario. Sus
atributos son:
‣ Atributo id: (obligatorio) identificador único del campo, por ejemplo, "cm:name".
‣ Atributo for-mode: (opcional, cadenas separadas por comas) especifica cuando
debe aparecer el campo sobre el que se aplica. Sus valores válidos son "view",
"edit" y "create". Si el atributo no se especifica, aparecerá en todos los modos. Si
queremos que el campo sólo aparezca en modo view y edit su valor será
"view,edit".
‣ Atributo force: (opcional, booleano): hay campos que pueden ser opcionales para
un item, por ejemplo, por defecto pueden no ser devueltos por el servidor. Cuando
este atributo está a true informa al servicio de formularios (FormService) que debe
hacer lo que sea para encontrar y devolver una definición de ese campo.

‣ Elemento hide: este elemento tiene sentido cuando varios ficheros de
configuración trabajan de forma combinada haciendo que un campo
no sea visible cuando previamente lo era. Sus atributos son:
‣ id (obligatorio, string): identificador único del campo, por ejemplo, "cm:name".
‣ Atributo for-mode: (opcional, cadenas separadas por comas) especifica cuando no
debe aparecer el campo sobre el que se aplica. Sus valores válidos son "view",
"edit" y "create". Si el atributo no se especifica, aparecerá en todos los modos. Si
queremos que el campo sólo aparezca en modo view y edit su valor será
"view,edit".
<forms>
<form>
<field-visibility>
<hide id="cm:title" />
<hide id="cm:description" />
</field-visibility>
</form>
</forms>
</config>
‣ El elemento appearance se encarga de definir la apariencia de los
diferentes controles que aparecen en el formulario (look&feel).
‣ Ejemplo:
<forms>
<form>
<appearance>
<set id="dublin-core" appearance="bordered-panel"
label="Dublin Core" />
<field id="cm:publisher" set="dublin-core" />
<field id="cm:contributor" set="dublin-core" />
<field id="cm:type" set="dublin-core" />
...
</appearance>
</form>
</forms>
</config>

‣ Elemento set: permite definir grupos de campos. Sus atributos son:
‣ id (obligatorio, string): especifica el identificador único del conjunto.
‣ parent (opcional, string): permite conjuntos anidados.
‣ appearance (opcional, string): especifica cómo debe renderizarse en grupo. Los
valores son "fieldset", "panel", "bordered-panel", "title" y "whitespace". Si este
atributo no aparece no será renderizado. Si el campo aparece “” el conjunto se
renderizará sin nada especial.
‣ template (opcional, string): especifica la ruta de la plantilla usada para renderizar el
grupo, permitiendo así personalización de los campos.
‣ label-id (opcional, string): especifica la clave en resource bundle key asociado al
campo.
‣ label (opcional, string): especifica la etiqueta del conjunto.
‣ Elemento field: controla la apariencia de cada campo, desde la etiqueta
al control que debemos usar. Sus atributos son:
‣ id (obligatorio, string).
‣ label-id (opcional, string).
‣ label (opcional, string).
‣ description-id (opcional, string).
‣ description (opcional, string).
‣ help-id (opcional, string).
‣ help (opcional, string).

‣ Elemento field (cont.):
‣ read-only (opcional, boolean): informa al generador de formularios que el campo
debe renderizarse como editable cuando el formulario esté en modo "edit" o
"create".
‣ mandatory (opcional, boolean): define el campo como obligatorio.
‣ set (opcional, string): especifica el identificador único de un fieldset indicando que
se encuentra dentro de él. Si el atributo se omite el campo pertenece al fieldset por
defecto.
‣ Ejemplos appearance:
<forms>
<form>
<appearance>
<field id="cm:name" label="File Name"
description="The file name of the content" />
</appearance>
</form>
</forms>
</config>

‣ Elemento control: este elemento es hijo de field y define el tipo de
control a utilizar para un determinado campo. Sus atributos son:
‣ template (opcional, string): Specifies the absolute path to the Freemarker template
to use to represent the field.
‣ Ejemplo:
<forms>
<form>
<appearance>
<field id="cm:title">
<control template="/org/alfresco/components/form/controls/textfield.ftl" />
</field>
</appearance>
</form>
</forms>
</config>
‣ Elemento control-param:
‣ Atributo name (obligatorio, string): nombre del parámetro que se pasa a control de
la plantilla.
‣ Ejemplo:
<forms>
<form>
<appearance>
<field id="cm:description">
<control>
<control-param name="rows">10</control-param>
</control>
</field>
</appearance>
</form>
</forms>
</config>

‣ Ejemplos: propiedad description
<forms>
<form>
<appearance>
<control>
<control-param name="rows">10</control-param>
</control>
</field>
</appearance>
</form>
</forms>
</config>
‣ Ejemplos: propiedad description renderizada en un campo rico.
<forms>
<form>
<appearance>
<control template="/org/alfresco/components/form/controls/richtext.ftl">
<control-param name="editorAppearance">full</control-param>
</control>
</field>
</appearance>
</form>
</forms>
</config>

‣ Elementos constraint-handlers y constraint: el elemento constraint
que función JS usar para chequear restricciones. Sus atributos son:
‣ type (obligatorio, string): identificador de una restricción, por ejemplo, LIST.
‣ validation-handler (obligatorio, string): nombre de la función JS llamada cuando el
campo se valida.
‣ message-id (opcional, string): clave asociada a resource bundle utilizado cuando la
validación falla. Si este atributo existe reemplaza el mensaje por defecto. Tiene
precedencia sobre el atributo message.
‣ message (opcional, string): mensaje que se genera si la validación falla.
‣ event (opcional, string): especifica qué evento activa al manejador de validación.
Este string coincide con eventos DOM estándares: "keyup", "blur" etc. El valor por
defecto es "blur".
‣ Elementos constraint-handlers y constraint:
‣ Ejemplo:
<config>
<forms>
<constraint-handlers>
<constraint type="MANDATORY"
validation-handler="Alfresco.forms.validation.mandatory"
event="keyup" />
</constraint-handlers>
</forms>
</config>

‣ Elemento dependencies: define la lista de ficheros JavaScript y CSS
necesarios para el funcionamiento del formulario.
‣ El elemento js representa un fichero js y css un fichero css. Su único atributo es:
‣ src (obligatorio, string): especifica la ruta absoluta desde el raís de la aplicación web (no
incluido el contexto de la web).
<config>
<forms>
<dependencies>
<css src="/fdk/accordion/accordion.css" />
<js src="/fdk/accordion/accordion-min.js" />
</dependencies>
</forms>
</config>
‣ Más información
‣ http://wiki.alfresco.com/wiki/Forms

Formulario de búsqueda avanzada
‣ Se define el formulario de búsqueda para cada tipo definiendo titulo y
descripción:
<config replace="true" evaluator="string-compare"
condition="AdvancedSearch">
<advanced-search>
<forms>
...
<form labelId="type.sc_whitepaper"
descriptionId="search.form.desc.sc_whitepaper">
sc:whitepaper
</form>
</forms>
</advanced-search>
</config>
Formulario de búsqueda avanzada
‣ Tenemos que especificar el detalle de cada formulario asociado a un
determinado tipo:
<config evaluator="model-type" condition="sc:whitepaper">
<forms>
<form id="search">
<field-visibility>
...
<appearance>
</appearance>
</forms>
</config>

Recargar Alfresco
Recargar Alfresco sin reiniciar
‣ Para recargar los modelos que hayamos puesto en la carpeta de
extensión sin parar el servidor podemos usar la consola
‣ http://localhost:8080/alfresco/faces/jsp/admin/repoadmin-console.
jsp
‣ y ejecutar el comando
‣ deploy model alfresco/extension/miModelo.xml

Recargar Alfresco sin reiniciar
‣ Para recargar las configuraciones de Alfresco Explorer (la interfaz Web)
basta ir a la consola
http://localhost:8080/alfresco/faces/jsp/admin/webclientconfig-console.
jsp
‣ y ejecutar el comando “reload”.
Recargar Alfresco con reinicio
‣ Basta parar el proceso de Alfresco y volver a lanzarlo.
‣ Múltiples mecanismos, depende del S.O. y del despliegue que se haya
hecho. Normalmente...
‣ sh alfresco.sh stop
‣ sh alfresco.sh start

Pruébalo
Probando las personalizaciones
‣ Sube un nuevo documento.
‣ Despliega en la primera pantalla el selector de tipos y comprueba que
aparece tu nuevo tipo personalizado. Selecciónalo.
‣ Comprueba que en el formulario de introducción de metadatos
aparecen las nuevas propiedades que hemos agregado al tipo de
contenido.

Búsquedas en Alfresco
‣ Introducción.
‣ Configurar búsquedas en Alfresco Explorer.
‣ Indexación de propiedades.
Introducción
‣ Con Alfresco podemos buscar en los contenidos y las propiedades de
los mismos. Soporta búsqueda a texto completo en el contenido,
independientemente del formato.
‣ Podemos restringir las búsquedas a ciertos espacios, categorías o
determinados tipos de contenido.

Introducción
‣ Búsquedas en Alfresco Explorer:
Introducción
‣ Búsqueda a texto completo: Por defecto, el contenido de Alfresco
soporta búsquedas a texto completo. Cualquier contenido que se suba
al repositorio es transformado internamente a texto y es indexado.

Configurar búsquedas en Alfresco Explorer
<config evaluator="string-compare" condition="Advanced Search">
<advanced-search>
<content-types>
<type name="custom:pressrelease" />
</content-types>
<custom-properties>
<meta-data type="custom:pressrelease"
property="custom:PRDate" />
<meta-data aspect="custom:CustomerDetails"
property="custom:CustomerName" />
<meta-data aspect="custom:CustomerDetails"
property="custom:NewCustomer" />
</custom-properties>
</advanced-search>
</config>
Tipo de contenido
Propiedad para buscar
Aspecto
Propiedad para buscar
Indexación de propiedades
‣ Introducción.
‣ Definición de índices en propiedades.

Introducción
‣ Cuando un documento se sube a Alfresco, por defecto, los metadatos
se extraen y se indexan en el acto, pero el contenido no tiene por qué
ser indexado en ese momento (depende).
<title>Content</title>
<properties>
<property name="cm:content">
<type>d:content</type>
<atomic>false</atomic>
<stored>false</stored>
<tokenised>true</tokenised>
</index>
</property>
</properties>
</type>
Definición de índices en propiedades
‣ El elemento index es el responsable de definir la indexación asociada a
cada propiedad en nuestro modelo de contenidos:
<type name="prefix:name">
...
<properties>
<property name="prefix:propertyName">
...
<index ...>
...
</index>
</property>
</properties>
</type>

‣ Atributo enabled: determina si la propiedad se indexa o no
...
<index enabled=”true”>
...
</index>
...
...
<index enabled=”false”>
...
</index>
...
‣ Elemento atomic:
...
<atomic> true|false </atomic>
</index>
...
‣ Si está a true, esa propiedad es indexada en el momento de la transacción, si está a
false, se indexará en background.
‣ La indexación de contenidos que necesitan transformación antes de ser indexados
(p. ej. PDF), solo serán atomic=true si la transformación tarda menos tiempo que el
valor especificado en el atributo lucene.maxAtomicTransformationTime. Todos los
transformadores por defecto están en la carpeta alfresco/WEB-INF/classes/
alfresco/services-context.xml.

‣ Elemento stored:
...
<stored> true|false </stored>
</index>
...
‣ Si está a true, el valor de la propiedad se almacenará en el índice y debe ser
consultado mediante la API de bajo nivel de Lucene.
‣ Esto es útil para debugging si queremos saber qué es exactamente lo que se está
indexando, pero no está recomendado en absoluto para producción ya que escribe
mucha más información en disco. Recomendado false.
‣ Elemento tokenised:
...
<tokenised> true|false|both </tokenised>
</index>
...
‣ Si está true, el valor de la cadena de la propiedad se tokeniza antes de ser
indexado.
‣ Si está a false, se indexará como una única cadena,
‣ Si está a both se harán las dos opciones.
‣ Valor recomendado true.

‣ Por defecto, los contenidos se indexan atómicamente en background,
no se almacenan en el índice y se dividen en distintos tokens antes de
ser indexados (esta es la política definida en cm:content que puede ser
sobreescrita).
<title>Content</title>
<properties>
<property name="cm:content">
<type>d:content</type>
<atomic>false</atomic>
<stored>false</stored>
<tokenised>true</tokenised>
</index>
</property>
</properties>
</type>
Custom Behaviors en Alfresco
‣ Introducción.
‣ Policies.
‣ Implementación de custom behavior en Java.
‣ Registro de custom behavior en Java.

Introducción
‣ Hay ocasiones en las que queremos desarrollar código para que se
encuentre altamente acoplado a un tipo de contenido.
‣ Habitualmente, es así porque necesitamos estar seguros de que se
ejecute cada vez que le ocurra algo a un determinado tipo de
contenido.
‣ Afortunadamente, Alfresco nos ofrece un mecanismo para resolver ese
tipo de circunstancias, llamado behavior.
‣ Behaviors se utilizan habitualmente en Alfresco. Los procesos de de
auditoría y versionado son ejemplos claros de este mecanismo.
‣ El desarrollo de estos elementos implica responder a dos preguntas:
‣ ¿Qué trozo de código queremos ejecutar?
‣ ¿Cuándo queremos ejecutar el trozo de código?
Introducción
‣ La entidad responsable de decidir cuándo se ejecuta un behavior se
denomina Policy.
‣ El trozo de código que se desea ejecutar puede ser programada en
Java o JavaScript (dos alternativas equivalentes).

Policies
‣ Como ya hemos comentado anteriormente, estos componentes
responsables de definir cuándo se ejecuta un behavior.
‣ Cada policy se nombra extendiendo una de las siguientes interfaces:
ClassPolicy, AssociationPolicy o PropertyPolicy. El contrato se define
mediante la interface Java Policy.
‣ Por ejemplo:
‣ El componente Node puede definir policies tales como onCreateNode,
beforeDeleteNode, onUpdateProperties, etc.
‣ El componente CheckOutCheckIn puede definir policies como onCheckOut,
onCheckIn, onCancelCheckOut, etc.
Policies
‣ La implementación de componentes es diferente a los tipos de
contenidos para permitir la inyección de comportamiento especiales
en los procesos.
‣ Los implementadores de componentes son responsable de definir el
contrato que describe cómo inyectar y cuándo la funcionalidad. Este
contrato se conoce como policy.
‣ Por ejemplo, el componente Node puede definir policies tales como
onCreateNode, beforeDeleteNode, onUpdateProperties, etc.
‣ El componente CheckOutCheckIn puede definir policies como
onCheckOut, onCheckIn, onCancelCheckOut, etc.
‣ Cada policy se nombra extendiendo una de las siguientes interfaces:
ClassPolicy, AssociationPolicy or PropertyPolicy. El contrato se define
mediante la interface Java Policy.

Policies
‣ Existen diferentes policies:
‣ CheckOutCheckInServicePolicies.
‣ ContentServicePolicies.
‣ CopyServicePolicies.
‣ LockServicePolicies.
‣ NodeServicePolicies.
‣ TransferServicePolicies.
‣ VersionServicePolicies.
‣ Cada una de estas interfaces contienen interfaces internas que nos
permiten puentear policies como necesitemos.
Policies
‣ La interface NodeServicePolicies define un conjunto de interfaces
internas y estáticas asociadas a los diferentes eventos:
‣ NodeServicePolicies.BeforeAddAspectPolicy.
‣ NodeServicePolicies.BeforeArchiveNodePolicy.
‣ NodeServicePolicies.BeforeCreateNodePolicy.
‣ NodeServicePolicies.BeforeCreateStorePolicy.
‣ NodeServicePolicies.BeforeDeleteAssociationPolicy.
‣ NodeServicePolicies.BeforeDeleteChildAssociationPolicy.
‣ ...
‣ http://dev.alfresco.com/resource/docs/java/repository/org/alfresco/
repo/node/NodeServicePolicies.html

Policies
‣ Ejemplo BeforeAddAspectPolicy:
Implementación de custom behavior en Java
‣ Desarrollo de una clase:
public class Rating implements
‣ Implementará tantas interfaces como policies desee manejar. En este ejemplo se
manejan dos tipos de eventos:
‣ Borrado de nodos.
‣ Creación de nodos.
NodeServicePolicies.OnDeleteNodePolicy,
NodeServicePolicies.OnCreateNodePolicy {
...

‣ Desarrollo de una clase (cont.):
// Dependencies
private NodeService nodeService;
private PolicyComponent policyComponent;
// Behaviours
private Behaviour onCreateNode;
private Behaviour onDeleteNode
...
‣ La clase tiene dos dependencias, éstas son gestionadas por Spring. El servicio de
nodos NodeService se utilizará para manejar nodos y PolicyComponent que se
utiliza which is used to bind the behavior to the policies.
‣ Desarrollo de una clase (cont.):
public void init() {
// Create behaviours
this.onCreateNode = new JavaBehaviour(this, "onCreateNode",
NotificationFrequency.TRANSACTION_COMMIT);
this.onDeleteNode = new JavaBehaviour(this, "onDeleteNode",
NotificationFrequency.TRANSACTION_COMMIT);
// Bind behaviours to node policies
this.policyComponent.bindClassBehaviour(
Qname.createQName(NamespaceService.ALFRESCO_URI, "onCreateNode"),
Qname.createQName(SomeCoModel.NAMESPACE_SOMECO_CONTENT_MODEL,
SomeCoModel.TYPE_SC_RATING),
this.onCreateNode
);
...

Registro de custom behavior en Java
‣ Una vez diseñada la clase Java que implementa la lógica de negocio,
debemos definirlo como un bean de Spring Framework. El
procedimiento es totalmente estándar.
‣ Se deben inyectar los servicios declarados previamente en la clase:
nodeService y policyComponent.
<bean id="ratingBehavior" class="com.someco.behavior.Rating"
init-method="init">
<property name="nodeService">
<ref bean="NodeService" />
</property>
<property name="policyComponent">
<ref bean="policyComponent" />
</property>
</bean>

Contenidos personalizados en alfresco ecm

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (11)

Similar a Contenidos personalizados en alfresco ecm

Similar a Contenidos personalizados en alfresco ecm (20)

Más de Ematiz Tecnología, S.L.

Más de Ematiz Tecnología, S.L. (10)

Último

Último (20)

Contenidos personalizados en alfresco ecm