Best practice per i tipi di contenuto in SharePoint

Question

Recentemente, abbiamo riscontrato un problema grave nella farm di produzione con i tipi di contenuto. Vorrei prima spiegare lo sfondo di questo problema.

Abbiamo una buona funzionalità di lavoro per l'installazione dei tipi di contenuto nelle aziende di produzione e di test. Abbiamo sviluppato e implementato (usando wsps) questa funzionalità di SharePoint in Visual Studio. Stiamo utilizzando lo publishing pages utilizzando layout di pagina e tipi di contenuto per aiutare gli editori di contenuti a pubblicare rapidamente le pagine web. Sfortunatamente, alcuni tipi di contenuto e colonne del sito sono stati aggiornati/aggiunti manualmente da alcune persone nella produzione, quindi ogni volta che I (sviluppatore) apporta alcune modifiche ai tipi di contenuto esistenti (utilizzando Visual Studio e attivazione/disattivazione delle funzionalità), SharePoint rimuove uno o due colonne (durante l'attivazione/disattivazione della funzione) da Tipi di contenuto; o le colonne che non sono state aggiunte in un modo pratico. Penso che la migliore pratica sia aggiornare i tipi di contenuto usando Visual Studio.

Ora, desidero garantire che le colonne del sito non vengano rimosse dai tipi di contenuto all'attivazione/disattivazione della funzione.

Nota: La nostra caratteristica per tipo di contenuto attivazione/disattivazione non detiene alcuna dipendenza di attivazione nel Feature.xml

Answer 1

Approccio consigliato

Sulla base di tutti questi fattori, il mio suggerimento sarebbe quello di:

• Creare due caratteristiche: una per il markup originale e uno per apportare modifiche. (Oppure puoi inserirli nella stessa funzione, voglio solo distinguere tra dove fai cosa.)

• La funzione originale deve contenere la CAML per le colonne del sito e i tipi di contenuto. Ciò garantisce che gli ID siano stati assegnati prima del tipo e rimangano costanti.

• Se si desidera aggiornare una Colonna sito modificando quasi tutto tranne il relativo tipo Campo, farlo utilizzando un ricevitore di funzioni. In questo modo, puoi chiamare il metodo Update e passare un valore booleano che indica se vuoi che tutte le risorse esistenti nel sito che ereditano da questo aggiornamento (qualcosa che non potresti fare tramite CAML).

• È inoltre possibile aggiungere una colonna sito esistente (fornita tramite la funzione CAML) a un tipo di contenuto esistente (fornito tramite la funzione CAML). Questo è utile se la colonna non faceva parte di quel tipo di contenuto prima, ecc.

• In uno scenario come quello appena menzionato nell'ultimo punto elenco, è necessario disattivare e rendere reattiva la funzione CAML (per eseguire il provisioning nuove risorse) prima di chiamare il ricevitore funzione. Cosa significherà questo per il sito? Dal momento che tutte le colonne del sito e i tipi di contenuto negli elenchi nel sito utilizzano gli stessi ID di quelli forniti nella radice della raccolta siti, la rimozione della parent dalla raccolta siti non la cambierà. Potrebbe lasciarlo orfano temporaneamente, (ad es.non ci sarà alcuna relazione tra quell'elemento e un elemento nella radice della Raccolta siti, ma funzionerà come sempre, dal momento che è una copia completamente funzionante dell'elemento originale) finché non riattiverai la Caratteristica che mette l'oggetto di nuovo nella raccolta siti. È come se i genitori andassero in vacanza quando si disattiva la funzione e tornano a casa quando si attiva nuovamente la funzione. È possibile scegliere come mantenere la CAML e il ricevitore funzione, poiché si hanno due scenari: raccolte siti esistenti e nuove.

• È possibile stabilire una politica in base alla quale ogni volta che si scrive codice nel ricevitore funzioni per aggiornare una colonna del sito o un tipo di contenuto, è necessario apportare anche la modifica alla CAML. Ciò significherebbe che ogni volta che hai attivato la funzione CAML in una raccolta di siti "nuova", la CAML sarebbe stata aggiornata e accurata; non sarebbe necessario eseguire la funzione "updater". (Nel tuo ricevitore di funzioni, dovresti assicurarti di fare qualche controllo extra per assicurarti che una colonna del sito non appartenga già a un tipo di contenuto prima di aggiungerla, ecc. Nel caso in cui tale modifica sia già presente prima dell'esecuzione del codice.) Questo approccio significa che devi eseguire una sola caratteristica quando crei una nuova raccolta siti, ma significa anche che stai mantenendo le modifiche in due punti: nel ricevitore funzioni per apportare modifiche ai siti esistenti e nella tua CAML per i nuovi siti. È un approccio più pulito, ma contiene anche un elemento di ridondanza, che lascia sempre spazio all'errore umano.

• L'altro approccio è semplicemente supporre che ogni volta che viene attivata la funzione CAML di base, si eseguirà sempre il ricevitore di funzioni. Questo approccio dice che l'unica volta in cui cambi CAML è aggiungere una nuova colonna del sito o un nuovo tipo di contenuto; in caso contrario, tutte le modifiche si verificano nel ricevitore di funzioni. Questo approccio riduce la ridondanza, ma significa anche che il codice del ricevitore di caratteristiche potrebbe diventare abbastanza grande con tutte le modifiche nel tempo e potrebbe lasciare la tua CAML come "legacy" nel tempo.

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

Answer 2

Aggiornamento tipi di contenuto è ancora una delle parti meno sviluppate di Sharepoint che a volte causano problemi, in particolare in Content Scenari di distribuzione.

La cosa migliore nel tuo caso sarebbe quella di evitare sempre di apportare modifiche ai tipi di contenuto a mano (con UI)

Ogni volta che si sta installando il tipo di contenuto, assicurarsi di rimuovere quella precedente e quindi installare quello nuovo. (A volte non è possibile a causa di pagine già create al di fuori di esso).

Answer 3

mio attuale approccio alla distribuzione tipi di contenuto è quello di fare il più possibile utilizzando il codice piuttosto che CAML. In questo modo è facile controllare completamente la logica degli aggiornamenti, garantendo anche che le modifiche apportate manualmente non causino conflitti. Ho la struttura definita come attributi su un'interfaccia che uso anche per l'accesso ad una lista fortemente tipizzata, ma ci sono molti altri modi per farlo.

L'unico pezzo che non è disponibile nell'API sta impostando un ID di tipo di contenuto specifico, quindi è necessario disporre di un file caml per questo, ma è un file piccolo/semplice, non tenta di fare aggiornamenti e viene fatto riferimento solo a una funzione che eseguirà anche il codice di aggiornamento.