Tipos de contenido versus campo de lista personalizada

Question

Esta es una pregunta sobre las mejores prácticas y la intención de los diseñadores de SharePoint.

Soy bastante nuevo con SharePoint, y solo he trabajado en proyectos bastante pequeños. A menudo me encuentro creando listas y bibliotecas personalizadas. En este caso específico, tengo una biblioteca de documentos que mis usuarios usarán para editar y verificar colaboradamente el contenido de una gran cantidad de hojas de cálculo de Excel. Tengo una lista separada que, utilizando controladores de eventos, rastrea los cambios realizados en elementos en la primera lista.

Cuando hago este tipo de trabajo, generalmente solo creo una lista personalizada o una biblioteca de documentos personalizada donde uso la opción de menú "Crear columna" para agregar columnas. Casi nunca uso campos de los tipos de contenido preexistentes. De vez en cuando he creado un tipo de contenido personalizado para toda la lista, pero todo el proceso parecía más complicado y de mantenimiento de lo que era necesario. Sin embargo, supongo que hay algún problema relacionado con la escalabilidad o la reutilización que no estoy viendo aquí. ¿Es esta una pregunta relevante para hacer?

• ¿Hay alguna razón convincente por las cuales se deben usar tipos de contenido/columnas del sitio en lugar de campos de listas locales y personalizados?
• ¿Hay alguna razón convincente por las cuales se deben usar campos de lista locales y personalizados en lugar de tipos de contenido/columnas del sitio?
• ¿Hay algún problema más profundo que solo la duplicación de la funcionalidad cuando se trata, por ejemplo, evitando usar un tipo de lista de SharePoint estándar y, en su lugar, crear una lista personalizada que almacene la misma información?

Answer 1

La intención de diseño de los tipos de contenido es admitir la reutilización del esquema de la lista (o comportamientos). Entonces, si existe el requisito de crear muchas listas con la misma estructura, que a menudo es el caso, entonces el tipo de contenido lo permite. Sería inaceptable tener que crear esquemas de lista individualmente en esta situación y resultaría en un trabajo repetitivo propenso a errores. Por lo general, en los grandes sitios de SharePoint existe el requisito de hacer cumplir algún nivel de consistencia en los metadatos.

En el caso de que simplemente cree una sola lista, y no anticipa la creación de listas similares en otras partes del sitio, no hay razón para usar un tipo de contenido. Puede crear una lista personalizada ad-hoc. Lo mismo se aplica a los campos: las columnas del sitio son útiles donde desea crear metadatos consistentes en diferentes tipos y listas de contenido, pero no es necesario si no tiene ese requisito.

Los tipos de lista estándar son un punto de partida útil si tiene sentido para su lista personalizada. Por ejemplo, una lista de enlaces le brinda una funcionalidad adicional, por lo que si tiene algo más complicado pero es, en su núcleo, una lista de hipervínculos, este es un buen lugar para comenzar. Pero no hay nada de malo en crear una lista personalizada si no necesita esto.

Answer 2

Lo que dijo Bill (@spdoctor). Eso depende.

En relación con el #3, a medida que las soluciones con las que trabaja se mayor, tenderá a dividir sus soluciones en varias colecciones de sitios. Dado que los tipos de contenido tienen alcance de la recopilación de sitios, esto puede convertirse en un problema si no desea tener un mantenimiento redundante de sus tipos de contenido.

Para resolver esto, puede usar la nueva función SP2010, Tipo de contenido Hub. CT Hub es una galería administrada de tipos de contenido, que le permite publicar tipos de contenido en las colecciones de sitios.

Lee mas aquí.

Answer 3

Siempre creo columnas y tipos de contenido del sitio. Harsh Experience me ha dicho que cualquier cosa implementada probablemente se considerará una idea genial de alguien y solicitará que se implemente en otro lugar de la misma colección de sitios.

Si tiene una jerarquía de tipos de contenido en uso en múltiples listas dentro de los sitios web, y una solicitud de cambio significa que debe, por ejemplo, agregar una opción a una columna de elección que debe propagarse en todas las instancias, puede hacer fácilmente con tipos de contenido.

¿Una solicitud le pide que agregue esa opción a una sola lista que usa ese tipo de contenido? También es posible, ya que los "tipos de contenido de la lista" son en realidad instancias del tipo de contenido del sitio, que operan por su cuenta (aunque heredan del tipo de contenido del sitio).

Answer 4

A la primera pregunta - sí. Algunos datos son comunes en muchos lugares. Por ejemplo, puede tener una columna del sitio de 'trimestre financiero', y esto podría usarse en muchos lugares; El trimestre financiero sigue siendo el trimestre financiero, ya sea una solicitud de gastos o un informe de algún tipo, por lo que tiene sentido poder compartir esa columna entre los tipos. Conceptualmente, es lo mismo.

Del mismo modo, los tipos de contenido pueden ser aplicables en múltiples ubicaciones. Por ejemplo, un tipo de contenido de documento de 'gastos de viaje' es lo mismo, ya sea en el sitio de equipo de 'ventas' o el sitio de 'ingeniería'. Al convertirlo en el mismo tipo de contenido, puede encontrar todas las cosas por el tipo de contenido. Luego podría buscar fácilmente todos los gastos de viaje (hay algunas formas de hacerlo)

En cuanto a por qué usar campos locales o tipos de contenido (segunda pregunta), bueno, a veces las cosas anteriores no son ciertas, a veces los conceptos son particulares para un solo dominio. Por ejemplo, las 'hojas de trabajo de ingeniería' solo pueden ser utilizadas por los ingenieros, por lo que tiene sentido que eso pueda ser logcal para su sitio en particular. No sé si eso es convincente, pero es una razón.

La regla general de la que paso es que si algo solo se usará una vez, está bien tener un tipo/campo de contenido de la lista local.