donc quelques questions concernant les types de contenu:
D'abord, les types de contenu est disponible en deux saveurs: les types de contenu du site et les types de contenu de la liste. Les types de contenu de site sont des "modèles" qui résident dans une galerie. Lorsqu'un type de contenu de site est utilisé dans une liste, le type de contenu est instancié en tant que type de contenu de liste dans la liste donnée. Deuxièmement, vos types de contenu pourraient être créés et modifiés de plusieurs façons, ce qui permettrait de décider dans lequel des trois modes vos données sont présentes dans la base de données. Si vous avez créé le type de contenu à l'aide de l'interface graphique ou d'un code personnalisé à l'aide de l'API, vos types de contenu de site et vos types de contenu de liste sont dans l'état "base de données uniquement" de la base de données. Cela signifie qu'il cherche dans la base de données les définitions du type de contenu.
Si vous avez créé le type de contenu en tant que fonctionnalité dans CAML, votre le site type de contenu est ghosted (ou non personnalisé que nous sommes censés appeler v3) dans la base de données. Cela signifie fondamentalement que la base de données recherche dans la fonction XML de la ruche 12 les colonnes de site qui composent le type de contenu. Cela devrait donc signifier que vous pourriez mettre à jour la fonctionnalité, et vous auriez de nouvelles colonnes de site disponibles dans le type de contenu de mise à jour, n'est-ce pas?
Malheureusement: rappelez-vous que nous avions aussi des types de contenu de liste? Le bummer ici est, que ces types de contenu de liste sont instanciés en utilisant le code, ainsi ils sont dans l'état "de base de données seulement". Cela signifie que vos modifications ne seront visibles que dans les types de contenu de votre site, mais pas dans les listes existantes utilisant ce type de contenu!
Il existe plusieurs méthodes pour résoudre ce problème, la solution dépend de vos besoins et du type de modifications que vous effectuez (suppression de champs, ajout de champs, modification de champs). Par exemple, vous voudriez souvent conserver vos méta-données d'élément existantes, même si le type de contenu change au fil du temps. Si vous faites passer les modifications dans le type de contenu de la liste par le biais du code, vous perdrez les données stockées dans les champs modifiés/supprimés. Une solution à cela serait d'ajouter un nouveau type de contenu basé sur l'ancien mais avec les champs modifiés.Vous ajouteriez le nouveau type de contenu (via le code ou l'entité XML) et utiliseriez un récepteur de fonctions ou un élément similaire pour propager le nouveau type de contenu à toutes les listes utilisant l'ancien type de contenu. Cela permettrait de conserver les anciennes méta-données mais de ne pas ajouter de nouveaux éléments en utilisant d'autres méta-données.
L'approche mentionnée dans l'autre réponse à cette question serait préférable si vous avez un accès direct à l'environnement de production et si le plan de gouvernance de votre client le permet. Comme pour d'autres artefacts dans SharePoint, il est recommandé de déployer les types de contenu de manière structurée. L'ajout de nouveaux types de contenu de manière non structurée influencerait la pertinence de la recherche (propriétés gérées) et pourrait également affecter la taxonomie générale du site (colonnes de sites non réutilisées, etc.), même s'il est possible d'ajouter directement ces modifications dans un site de production, je ne le recommanderais pas! Cela m'amène à l'approche finale que je recommanderais, au moins pour les futurs types de contenu: Créez vos types de contenu par programme depuis le début en utilisant un récepteur de fonctions! De cette façon, vous connaissez toujours l'état réel de vos types de contenu (base de données uniquement) et vous pouvez avoir une approche structurée pour gérer les changements dans le futur! Vous pouvez trouver plusieurs façons de le faire en recherchant sur Google les types de contenu 'créer' SharePoint '
Pour être complet: J'ai mentionné trois modes. Le dernier mode dans lequel votre type de contenu peut être est "UnGhosted". Cela signifie que votre type de contenu a été créé à l'aide de la fonctionnalité XML, mais qu'il a été déconnecté de la source XML d'origine dans la ruche 12.
Mon ami Søren Nielsen a quelques bons points sur les types de contenu dans Audit your Content Type Hierarchy. Certains des problèmes décrits ci-dessus peuvent être trouvés brièvement mentionnés dans un article MSDN Updating Content Types. Gary Lapointe dispose également d'une extension STSADM qui résout certains des problèmes liés aux types de contenu, voir Propagate Content Type Changes.
Désolé pour la diatribe, mais le sujet est complexe et nécessite une explication approfondie pour éviter toute idée fausse.
Si vous avez initialement créé vos types de contenu dans une fonction, recommander l'approche du récepteur de fonctions? –
Salut, votre réponse a été très utile, au moins pour moi :) Il est parfois très difficile de trouver de la documentation dans le monde de Sharepoint. Je suis également curieux de la mise à jour des types de contenu créés par fonctionnalité :) Merci beaucoup de toute façon – drax
Si vous utilisez le modèle objet ou l'enfoncement en utilisant l'interface graphique est plus une question de pratiques de déploiement. Le script dans le récepteur de fonctions fait le samething, mais vous donne une plus grande liberté de gérer les CT existants comme vous voulez et b) un processus de déploiement structuré qui peut être testé dans preprod etc. –