Definición XML de metadatos

Los metadatos de la aplicación se basan en una definición XML formal. El DTD (Document Type Definition) define la estructura y los elementos y atributos válidos de un documento XML.

Nota

Puede ver el último DTD en nuestro sitio web http://www.openkm.com/dtd/property-groups-{major}.{minor}.dtd, donde {major} y {minor} son dos números (versión mayor y versión menor). Por ejemplo, la ubicación del DTD para la versión 3.10 es http://www.openkm.com/dtd/property-groups-3.10.dtd

Precaución

Cada versión de la aplicación solo soporta un par de definiciones DTD. Lea Application version compatibility table para ver cuáles soporta su aplicación.

Precaución

Una vez registrados los metadatos, recuerde habilitarlos en el perfil de usuario, en Administration > Profiles, pestaña General, Metadata Groups.

Esqueleto XML básico

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.10.dtd">
<property-groups>

</property-groups>

• El DOCTYPE es una definición formal de un DTD. En el ejemplo anterior se usa property-groups-3.10.dtd.
• El XML comienza con la etiqueta y termina con . Dentro de esta jerarquía se definen los grupos de metadatos.

Definición de un grupo de metadatos

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.10.dtd">
<property-groups>
  <property-group label="Consulting" name="okg:consulting">

  </property-group>
</property-groups>

• Cada bloque …</property-group identifica el inicio y el fin de una nueva definición de grupo de metadatos.
• Cada grupo de metadatos tiene una etiqueta -usada por la interfaz de usuario- Consulting.
• Cada grupo de metadatos tiene un nombre único, okg:consulting.
• El nombre del grupo de metadatos siempre debe empezar por “okg:” (OpenKM Group).
• No use caracteres especiales en el nombre.

Attribute	Description	Required
label	El texto mostrado como etiqueta en la interfaz de usuario.	true
name	Identificador único del campo. Dos grupos de metadatos no pueden tener el mismo nombre. El nombre debe ser único. El nombre debe empezar por “okg:”. Use solo letras, números y guion bajo: “0-9a-zA-Z_”. Recomendamos “snake_case” en vez de “camelCase” para nombres de columna más claros.	true
visible	Muestra u oculta el metadato. Valores permitidos: - true. - false. Por defecto, los metadatos son visibles.	false
readonly	Los valores de metadatos no pueden modificarse desde la interfaz de usuario; solo pueden modificarse vía API. Valores permitidos: - true. - false. Por defecto, los metadatos son modificables.	false
defaultValueClassName	Establece una clase Java personalizada para establecer valores iniciales por defecto.	false

Ejemplo básico

Tipos de campo disponibles:

• Checkbox
• Input
• Iframe
• Select
• Separator
• Suggestbox
• Text
• TextArea

Más información sobre los elementos de tipo de campo en Metadata fields.

Nota

Es buena práctica usar el nombre del grupo de metadatos como base para crear los nombres de los campos de metadatos. Por ejemplo, okp:consulting.code usa okg:consulting como base (cambiando okg por okp). Esto ayuda a determinar a qué grupo de metadatos pertenece cada campo.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.10.dtd">
<property-groups>
  <property-group label="Consulting" name="okg:consulting">
    <input label="Input label" name="okp:consulting.input1" />
    <separator label="Separator label" name="okp:consulting.separator" />
    <input label="Input label" name="okp:consulting.input2" />
  </property-group>
</property-groups>

Usando el DTD desde el sistema de ficheros

Si el servidor no tiene acceso a Internet, el fichero DTD debe estar accesible de alguna otra forma; por ejemplo, puede guardar una copia en su servidor de aplicación.

Precaución

La definición XML debe cambiarse para referenciar la nueva ubicación del DTD; de lo contrario, obtendrá un error de aplicación al procesar el fichero DTD.

Puede ser una ruta del sistema de ficheros (ejemplo abajo) o una URL de intranet válida.

<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "file:///home/openkm/property-groups-3.10.dtd">

• En el ejemplo, /home/openkm/property-groups-3.10.dtd es la ruta del sistema de ficheros al fichero.

Cómo se almacenan los metadatos en OpenKM

Cuando registra una nueva definición de metadatos en OpenKM, los valores de los metadatos se almacenan en dos tablas separadas: una tabla para los valores de metadatos actuales y otra para los valores históricos.

Ejemplo:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.10.dtd">
<property-groups>
  <property-group label="Consulting" name="okg:consulting">
    <input label="Input label" name="okp:consulting.input1" />
    <separator label="Separator label" name="okp:consulting.separator" />
    <input label="Input label" name="okp:consulting.input2" />
  </property-group>
</property-groups>

Tras registrar la definición de metadatos anterior, se crearán dos tablas con estas columnas:

• OKM_PGRP_CUR_CONSULTING (usada para los valores de metadatos actuales)
  • RGT_UUID: ID del nodo que tiene este metadato
  • RGT_PRO_INPUT1: Valor de la propiedad okp:consulting.input1
  • RGT_PRO_INPUT2: Valor de la propiedad okp:consulting.input2
  • RGT_PRO_SEPARATOR: Valor de la propiedad okp:consulting.separator
• OKM_PGRP_HIS_CONSULTING (usada para los valores históricos de metadatos)
  • RGT_UUID: ID del nodo que tiene este metadato
  • RGT_VERSION: ID de la versión relacionada
  • RGT_PRO_INPUT1: Valor de la propiedad okp:consulting.input1
  • RGT_PRO_INPUT2: Valor de la propiedad okp:consulting.input2
  • RGT_PRO_SEPARATOR: Valor de la propiedad okp:consulting.separator

Nota

El prefijo usado en todas las columnas será RGT_.

La columna llamada RGT_UUID contiene el valor del UUID del nodo.

Precaución

Tenga cuidado con la limitación de Oracle de 32 caracteres para nombres de tabla y columna.

Recomendamos “snake_case” en vez de “camelCase” para nombres de columna más claros.

Por ejemplo, esta definición crearía el campo de tabla RGT_PRO_RETURNPLACE:

<input label="Return place" name="okp:sample.returnPlace" />

Pero esta otra crearía el campo de tabla RGT_PRO_RETURN_PLACE, más legible:

<input label="Return place" name="okp:sample.return_place" />

Tamaño de columna por defecto según el tipo:

Type	Size
Input	128 caracteres
Select	128 caracteres
SuggestBox	128 caracteres
TextArea	256 caracteres

Si tiene valores de metadatos más largos, debería aumentar el tamaño de columna con el atributo “dbColumnSize”. Vea el ejemplo de abajo:

Precaución

El valor del atributo “dbColumnSize” solo se aplicará la primera vez que registre el grupo de metadatos o cuando añada un fichero nuevo. Una vez creada la columna en la base de datos, cambiar el valor del atributo “dbColumnSize” no actualizará el tamaño de la columna. Si quiere actualizar el tamaño de la columna después de crearla, debe aplicar los cambios directamente con un cliente de base de datos.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.10//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.10.dtd">
<property-groups>
  <property-group label="Consulting" name="okg:consulting">
    <input label="Input label" name="okp:consulting.input1" dbColumnSize="256"/>
    <separator label="Separator label" name="okp:consulting.separator" />
    <input label="Input label" name="okp:consulting.input2" dbColumnSize="512"/>
  </property-group>
</property-groups>