Mejores prácticas para los tipos de contenido en SharePoint

Question

Recientemente, nos encontramos con un problema grave en la granja de producción con los tipos de contenido. Me gustaría explicar el trasfondo de este problema primero.

Tenemos una buena función de trabajo para la instalación de tipos de contenido en granjas de producción y prueba. Desarrollamos e implementamos (usando wsps) esta característica de SharePoint en Visual Studio. Estamos utilizando el publishing pages utilizando diseños de página y tipos de contenido para ayudar a los editores de contenido a publicar rápidamente las páginas web. Desafortunadamente, algunas personas en la producción han actualizado/agregado algunos tipos de contenido y columnas del sitio, por lo que siempre que yo (desarrollador) realice algunos cambios en los tipos de contenido existentes (utilizando Visual Studio y activación/desactivación de funciones), SharePoint elimina uno o dos columnas (durante la activación/desactivación de características) de los tipos de contenido; o las columnas que no se han agregado de la mejor manera posible. Creo que la mejor práctica es actualizar los Tipos de contenido usando Visual Studio.

Ahora, deseo asegurarme de que las columnas del sitio no se eliminen de los Tipos de contenido al activarse/desactivarse las funciones.

Nota: Nuestra característica de contenido de este tipo de activación/desactivación no se cumple ninguna dependencia de activación en el feature.xml

Answer 1

enfoque recomendado

Sobre la base de todos estos factores, mi sugerencia sería:

• Crear dos características: una para el marcado original y uno para hacer cambios. (O puede ponerlos en la misma función; solo quiero diferenciar entre dónde se hace qué).

• La característica original debe contener el CAML para Columnas del sitio y tipos de contenido. Esto garantiza que los ID se hayan asignado antes del tipo y permanezcan constantes.

• Si desea actualizar una Columna del sitio cambiando casi cualquier cosa, excepto su Tipo de campo, hágalo utilizando un Receptor de funciones. Al hacer esto, puede llamar al método Update y pasar un booleano que indica si desea actualizar todos los activos existentes en el sitio que hereda de esto, (algo que no podría hacer a través del CAML)

• También puede agregar una Columna del sitio existente (que aprovisionó mediante la función CAML) a un Tipo de contenido existente (que se aprovisionó mediante la función CAML). Esto es útil si la columna no era parte de ese tipo de contenido antes, etc.

• En un escenario como el que acabo de mencionar en el último punto, es necesario desactivar y reactivar la función CAML (para aprovisionar el nuevos activos) antes de llamar a su Feature Receiver. ¿Qué significará esto para el sitio? Dado que todas las columnas del sitio y los tipos de contenido en las listas del sitio usan las mismas ID que las aprobadas en la raíz de la colección de sitios, eliminar su elemento principal de la colección de sitios no cambiará eso. Puede dejarlo huérfano temporalmente, (es decirno habrá relación entre ese elemento y un elemento en la raíz de la colección de sitios, pero funcionará de la misma manera que siempre, ya que es una copia completamente funcional del elemento original) hasta que reactive la característica que coloca el elemento de vuelta en la Colección de sitios. Es como si los padres se fueran de vacaciones cuando desactivas la función y vuelven a casa cuando vuelves a activar la función. Tiene la opción de mantener el CAML y el receptor de funciones, ya que tiene dos escenarios: colecciones de sitios existentes y otras nuevas.

• Puede establecer una política que cada vez que escriba código en su Feature Receiver para actualizar una Columna de sitio o Tipo de contenido, también deberá realizar el cambio en su CAML. Eso significa que cada vez que activó la función CAML en una Colección de sitios "nueva", la CAML estaría actualizada y sería precisa; no habría necesidad de ejecutar la función "actualizador". (En su Receptor de funciones, debe asegurarse de hacer alguna comprobación adicional para asegurarse de que una Columna del sitio ya no pertenezca a un Tipo de contenido antes de agregarla, etc. en caso de que el cambio ya esté en su lugar antes de que se ejecute el código). Este enfoque significa que solo tiene que ejecutar una característica al crear una nueva colección de sitios, pero también significa que mantiene los cambios en dos lugares: en su receptor de funciones para realizar cambios en sitios existentes y en su CAML para sitios nuevos. Es un enfoque más limpio, pero también contiene un elemento de redundancia, que siempre deja espacio para errores humanos.

• El otro enfoque es simplemente suponer que cada vez que se activa la función CAML base, siempre va a ejecutar el Receptor de funciones. Este enfoque indica que la única vez que cambiaría el CAML es agregar una nueva Columna de sitio o un nuevo Tipo de contenido; de lo contrario, todos los cambios suceden en el Receptor de funciones. Este enfoque reduce la redundancia, pero también significa que su código de Feature Receiver podría ser bastante grande con todos sus cambios a lo largo del tiempo, y podría dejar su CAML como un "legado" con el tiempo.

Src: http://blog.beckybertram.com/Lists/Posts/Post.aspx?List=eb3e1762%2Dbab0%2D4e96%2D8bc5%2Dd67d6e6bfd44&ID=18

Answer 2

Actualización de tipos de contenido sigue siendo una de las partes subdesarrolladas de Sharepoint, que a veces causa problemas, sobre todo en el contenido Escenarios de implementación.

Lo mejor en tu caso sería evitar siempre hacer ningún cambio en los tipos de contenido con la mano (usando la interfaz de usuario)

Siempre que va a instalar el tipo de contenido, asegúrese de que se quita la anterior y luego instalar el nuevo. (Algunas veces no es posible debido a que las páginas ya han sido creadas).

Answer 3

Mi enfoque actual para la implementación de tipos de contenido es hacer lo más posible el uso de código en lugar de CAML. De esta forma, es fácil controlar completamente la lógica de las actualizaciones, lo que incluye garantizar que los cambios realizados manualmente no causen conflictos. Tengo la estructura definida como atributos en una interfaz que también uso para el acceso a listas fuertemente tipadas, pero hay varias otras maneras en que puede hacerlo.

La única pieza que no está disponible en la API es establecer un ID de tipo de contenido específico, por lo que debe tener un archivo caml para eso, pero es un archivo pequeño/simple, no intenta hacer actualizaciones y solo se hace referencia a partir de una característica que también ejecutará el código de actualización.