Il modo migliore per confezionare la pubblicazione di tipi di contenuto

Question

Al momento sto progettando su come confezionare i miei tipi di contenuto editoriale in un WSP per rendere l'implementazione della produzione di più facile. Mi è venuto un incrocio le seguenti scelte 1- creare un ricevitore funzione di programmazione e di creare il tipo di contenuto e dei suoi campi 2- utilizzare l'Elements.xml a disposizione i tipi di contenuto.

Ora sento che la soluzione Elements.xml è più simile a una soluzione standard, anche se penso che quella programmatica è più gestibile dal momento che abbiamo di confezionare circa 10 tipi di contenuto con un sacco di campi all'interno.

Quindi, dalla tua esperienza qual è l'opzione migliore? Inoltre, se volessimo fare un certo cambiamento per i nostri tipi di contenuto, ciò che è l'opzione che è più aggiornare amichevole

Answer 1

Non sono d'accordo con James.

1. Lo SPContentType in SharePoint 2010 ha un costruttore nuova che consente di specificare il tipo di contenuto id.

2. L'aggiunta del Inherits attributo dell'elemento ContentType rende il comportamento dei tipi di contenuto descritto in CAML incoerente .

3. Infine, il meccanismo di aggiornamento caratteristica è grande se si sta aggiungendo i campi, ma non gestisce altre situazioni in modo che si sta per avere a ripiegare in codice in ogni caso.

Il mio suggerimento è di creare tutti i tuoi campi e tipi di contenuto nel codice.

Answer 2

La distribuzione di tipi di contenuto tramite l'Elements.xml consente di definire Ids di contenuti di tipo così come i vostri ID di colonna del sito (che non si può fare tramite l'API a meno che non si utilizza AddFieldAsXml) Questo rende la vita molto più facile in seguito nel codice , come gli ID rimarranno costanti durante tutto il ciclo di vita di sviluppo tra gli ambienti.

Con UpgradeActions funzionalità di SharePoint 2010, l'applicazione degli aggiornamenti è relativamente semplice.

Confezione 10 tipi di contenuto con molti FieldRefs suoni inizialmente scoraggiante in un file XML, ma in realtà è easer per tenerlo in XML piuttosto che il più prolisso metodo di memorizzazione che le informazioni di provisioning in molte, molte righe di codice.