una - Sharepoint: ¿Qué sucede con las listas basadas en el tipo de contenido cuando se actualiza el tipo de contenido?
tipos de listas en sharepoint (2)
Tengo una especie de pregunta hipotética (al menos por ahora :))
Digamos que creo una lista basada en algún tipo de contenido personalizado. Agrego unos 1000 elementos en esa lista (en producción). Luego viene el cliente y él dice que necesita modificar ese tipo de contenido personalizado.
¿Qué sucede con la lista si modifico el tipo de contenido personalizado? ¿Se actualizará automáticamente (lo dudo)? ¿Y qué hay de los elementos de la lista ya creados?
¿Alguno de ustedes tiene alguna experiencia con esto?
Cuando actualiza el tipo de contenido, hay una casilla en la que puede hacer clic para actualizar los tipos de contenido secundarios. Al marcar esa casilla, se actualizarán los tipos de contenido de la lista.
Tenga en cuenta que si no marca la casilla para actualizar los tipos de contenido secundarios, entonces no hay forma de forzar la actualización más adelante. Por lo tanto, si no actualiza y luego desea que los tipos de contenido secundarios tengan la actualización, primero debe invertir la actualización y volver a implementarla.
.segundo
Entonces, un par de cuestiones con respecto a los tipos de contenido:
En primer lugar, los tipos de contenido vienen en dos tipos: tipos de contenido del sitio y tipos de contenido de la lista. Los tipos de contenido del sitio son "plantillas" que residen en una galería. Cuando se usa un tipo de contenido de sitio en una lista, el tipo de contenido se instancia como un tipo de contenido de lista en la lista dada.
En segundo lugar, sus tipos de contenido podrían crearse y modificarse de varias maneras, lo que decidiría en qué tres modos están presentes sus datos en la base de datos.
Si ha creado el tipo de contenido mediante la GUI o mediante un código personalizado que utiliza la API, tanto los tipos de contenido de su sitio como los tipos de contenido de la lista están en el estado "solo base de datos" en la base de datos. Eso significa que busca en la base de datos las definiciones del tipo de contenido.
Si ha creado el tipo de contenido como una función en CAML , el tipo de contenido de su sitio está fantasma (o no está personalizado, como se supone que debemos llamarlo en v3) en la base de datos. Eso significa básicamente que la base de datos busca en el XML de características en el 12-colmena para las columnas del sitio que compone el tipo de contenido. Entonces, eso debería significar que podría actualizar la característica, y tendría nuevas columnas de sitio disponibles en el tipo de contenido de actualización, ¿verdad?
Desafortunadamente no: ¿recuerdas que también teníamos tipos de contenido de lista? Lo malo de esto es que estos tipos de contenido de la lista se instancian usando código, por lo que están en el estado "solo base de datos". Significa que sus cambios solo se verán en los tipos de contenido de su sitio, pero no en las listas existentes que usan ese tipo de contenido.
Existen varios enfoques para solucionar este problema, la solución depende de cuáles sean sus necesidades y qué tipo de cambios está realizando (eliminación de campos, adición de campos, cambio de campos).
Por ejemplo, a menudo desearía mantener sus metadatos de elementos existentes, aunque el tipo de contenido cambie con el tiempo. Si avanza a través de los cambios en el tipo de contenido de la lista a través del código, perdería los datos almacenados en los campos modificados / eliminados. Una solución a esto sería agregar un tipo de contenido completamente nuevo basado en el anterior pero con los campos modificados. Agregaría el nuevo tipo de contenido (mediante código o utilizando la función XML) y usaría un receptor de funciones o similar para promocionar el nuevo tipo de contenido a todas las listas que usaban el tipo de contenido anterior y posteriormente marcar el tipo de contenido anterior como oculto. Eso permitiría mantener metadatos viejos pero no agregar nuevos elementos utilizando otros metadatos nuevos.
El enfoque mencionado en la otra respuesta a esta pregunta sería preferible si tiene acceso directo al entorno de producción y si el plan de gobierno de los clientes lo permite. Sin embargo, al igual que con otros artefactos en SharePoint, se recomienda implementar tipos de contenido de forma estructurada. Agregar nuevos tipos de contenido de forma no estructurada influiría en la relevancia de la búsqueda (propiedades administradas) y también podría afectar la taxonomía general del sitio (columnas del sitio que no se reutilizan, etc.), por lo que a pesar de que es posible agregar estos cambios directamente en un sitio de producción, ¡no lo recomendaría!
Eso me lleva al enfoque final que es el que recomendaría, al menos para los tipos de contenido futuros: ¡cree sus tipos de contenido programáticamente desde el principio usando un receptor de funciones! De esta forma siempre sabrá el verdadero estado de sus tipos de contenido (solo base de datos) y podrá tener un enfoque estructurado para gobernar los cambios en el futuro. Puede encontrar varias formas de hacer esto buscando en Google ''crear'' tipos de contenido "programáticamente SharePoint ''
Para completar: mencioné tres modos. El último modo en el que puede estar su tipo de contenido es "No fantasma". Esto significa que su tipo de contenido se creó utilizando la función XML, pero que se ha desconectado de la fuente XML original en la sección 12.
Mi amigo Søren Nielsen tiene algunos puntos buenos sobre Tipos de contenido en Auditar tu jerarquía de tipos de contenido . Algunos de los problemas descritos anteriormente pueden encontrarse brevemente mencionados en un artículo de MSDN Actualización de tipos de contenido . Gary Lapointe también tiene una extensión STSADM que aborda algunos de los problemas con los tipos de contenido, consulte Propagar cambios en el tipo de contenido .
Perdón por la diatriba, pero el tema es complejo y exige una explicación exhaustiva para evitar cualquier malentendido.