Cuando hablamos de integridad referencial (i.e. control de relaciones entre diferentes entidades) y de MOSS lo primero que nos viene a la cabeza es el concepto Lookup Columns (o columnas de búsqueda). Con ellas podemos crear columnas de sitio que hagan referencia a una lista concreta y que luego, al ser añadidas a un tipo de contenido conseguirían el efecto de lo que siempre hemos denominado Relación 1-N. Con el uso de estas columnas especiales podemos obtener algo similar a integridad referencial y, con un poco de trabajo y algún event handler podríamos afinarlo hasta el punto que quisiéramos.
Ahora bien, ¿qué sucedería si quisiéramos utilizar este concepto mezclado con un portal de publicación con variaciones? Un caso bastante normal con el que nos encontramos al trabajar en portales públicos en varios idiomas es el siguiente: contenido principal (producto) que está relacionado con contenido secundario (artículo relacionado). Como no podía ser de otra manera, tanto el producto como sus artículos relacionados deben visualizarse en diferentes idiomas y, por lo tanto, utilizamos variaciones de sitio. Si aplicamos el concepto mencionado anteriormente, podríamos crear una columna de sitio relacionada con productos y añadirla al tipo de contenido artículo relacionado. Tras muchas pruebas, veríamos como al generarse las variaciones este tipo de columna nos iba a causar muchísimos problemas. Acabaríamos intentando interceptar el evento de generación de variaciones de página para modificar su comportamiento y, en el mejor de los casos, acabaríamos creando una estructura de datos satélite y desarrollando todos los webparts necesarios para simular el comportamiento deseado. Los resultados de todo esto serían:
- Gran cantidad de código a generar, con las implicaciones en tiempo y esfuerzo que esto atañe.
- Poca posibilidad de reutilizar los desarrollos realizados
- Poco aprovechamiento de las características estándard de SharePoint.
Yo no soy partidario de ninguna de estas tres consecuencias y, por tanto, decidí darle algunas vueltas y plantear una solución alternativa, genérica y muy en línea con las capacidades del producto. A continuación enumeraré los puntos claves de esta solución:
- Añadir a todos los tipos de contenido personalizados una columna, que llamaremos PK y que, mediante un event handler asociado a dichos tipos de contenido, se inicializará con un valor único (GUID) en el momento de creación.
- Añadir campos a los tipos de contenido relacionados para alojar las relaciones. En el caso que nos ocupa, crearíamos un campo Producto en el tipo de contenido Artículo.
- Crear un control genérico que permite crear contenidos de un tipo determinado, desde la página de detalle de otro contenido relacionado. En nuestro ejemplo, añadiríamos el control dentro de la página de detalle de producto y lo configuraríamos para que generase artículos con el campo Producto rellenado automáticamente con el valor PK del producto que estamos visualizando y nos llevase a la página de detalle de dicho artículo.
Como podéis ver, dos desarrollos simples que pueden ser reutilizados en cualquier proyecto si se realizan convenientemente. Y lo que hace que todo resulte aún más simple es el hecho que, en el momento en que se creen variaciones de alguno de estos contenidos, los campos PK y Producto mantendrán sus valores sin necesidad de intervención alguna.
0 comentarios:
Publicar un comentario