Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

SPFieldCollection.AddField & AddFieldAsXml

Möchte man einer SharePoint-Liste pro­gram­ma­tisch ein Feld (eine Spalte) hin­zu­fü­gen, dann hat man ver­schie­dene Möglichkeiten, dies umzu­set­zen. SPFieldCollection stellt drei Methoden mit ver­schie­de­nen Überladungen zur Verfügung.

  • Add
  • AddFieldAsXML
  • AddLookup

In die­sem Artikel möchte ich spe­zi­ell auf die Unterschiede der bei­den ers­ten Methoden ein­ge­hen. Wann sollte man wel­che Methode ver­wen­den?

Folgendes Szenario:

Site-Column Öffentliche Ämter (Managed Metadata Field) soll einer Liste eines Webs der SiteCollection hin­zu­ge­fügt wer­den:

<Field 
    Type="TaxonomyFieldType" 
    DisplayName="Öffentliche Ämter" 
    Required="TRUE" 
    EnforceUniqueValues="FALSE" 
    Group="Custom" 
    ID="{BBB05D05-BBBD-BB5B-BB02-BBB738BB202B}" 
    SourceID="{81de0011-836c-43a5-b05a-d7fe9afa2907}" 
    StaticName="publicoffice" 
    InternalName="publicoffice" 
    Overwrite="TRUE" 
    xmlns="http://schemas.microsoft.com/sharepoint/">
    <Default />
</Field>

Die Definitionen für die TermSet-Zuweisung pas­siert im Code. Der StaticName und der InternalName lau­ten publi­cof­fice.

Möglichkeit 1:

var myList = currentWeb.Lists["MyList"];
var fieldToAdd = currentWeb.Site.RootWeb.Fields[new Guid("BBB05D05-BBBD-BB5B-BB02-BBB738BB202B")]
myList.Fields.Add(fieldToAdd);

Möglichkeit 2:

var myList = currentWeb.Lists["MyList"];
var fieldToAdd = currentWeb.Site.RootWeb.Fields[new Guid("BBB05D05-BBBD-BB5B-BB02-BBB738BB202B")];
var addToDefaultView = true;
myList.Fields.AddFieldAsXml(fieldToAdd.SchemaXml, addToDefaultView, SPAddFieldOptions.AddToAllContentTypes);

Auf den ers­ten Blick ist der wesent­li­che Unterschied der, dass Möglichkeit 2 ein direk­tes Hinzufügen in die Default-View ver­an­lasst und das Feld zusätz­lich zu allen ContentTypes hin­zu­fügt. (Hier kön­nen auch andere Felderoptionen über­ge­ben wer­den). Ansonsten sollte das Feld eigent­lich genau gleich hin­zu­ge­fügt wer­den, da das XML das­selbe ist, bzw. beim Hinzufügen über das SchemaXML das XML des ursprüng­li­chen Feldes ver­wen­det wird.

Was uns der Methodenname und auch die über­ge­be­nen Parameter aber nicht sagen ist, dass StaticName und InternalName unter­schied­lich gesetzt wer­den. Was bedeu­tet das?

Bei der Add-Methode wer­den Static- und InternalName ent­spre­chend der Site-Column gesetzt. Das heißt so wie das ursprünglich-definierte XML ver­öf­fent­licht wurde, so wer­den auch alle Eigenschaften für eine Spalte an einer Liste über­nom­men. Die SiteColumn wird als Vorlage genom­men. Die neue Spalte an der Liste ist mit der Site-Column "ver­knüpft".

Bei der AddFieldAsXml wer­den Static- und InternalName nicht, wie ursprüng­lich im XML defi­niert, gesetzt, son­dern neu gene­riert. Und zwar aus dem Titel! Das bedeu­tet in die­sem Fall, dass die bei­den Attribute unschöne Werte bekom­men:

aus

Öffentliche Ämter

wird dann

%5Fx00d6%5Fffentliche%5Fx0020%5F%5Fx00c4%5Fmter

Wann könnte das zum Problem wer­den? Ein Beispiel:

Wird über die Spalte gefil­tert, so wird der aktu­el­len Url ein Query-String ange­hängt. Dieser besteht unter ande­rem auch aus dem zu fil­tern­dem Feld (InternalName). Je nach­dem wel­che Add-Methode man ver­wen­det, wird sich der Query-String unter­schei­den:

Methode 1:

?FilterField1=publicoffice&FilterValue1=0&FilterOp1=In&FilterLookupId1=1&FilterData1=0%2C80510cd1%2Dd4f7%2D4a7f%2Db5ca%2D5050a5b14a76

Methode 2

&FilterField1=%5Fx00d6%5Fffentliche%5Fx0020%5F%5Fx00c4%5Fmter&FilterValue1=0&FilterOp1=In&FilterLookupId1=1&FilterData1=0%2C80510cd1%2Dd4f7%2D4a7f%2Db5ca%2D5050a5b14a76

Möchte man nun diese oder eine ähn­li­che Funktion nach­bil­den, so wird womög­lich der InternalName, bei einem durch AddFieldAsXml hin­zu­ge­füg­ten Feld,  nicht  mit dem ver­mu­te­ten Namen über­ein­stim­men. Der Wert kann nicht über die SiteColumn ermit­telt wer­den bzw. nur über den Titel und einer unschö­nen Encodierung.

FAZIT:

Werden die zusätz­li­chen FieldOptions, wie zum Beispiel SPAddFieldOptions.AddToAllContentTypes, nicht benö­tigt, dann sollte auf die klas­si­sche Add-Methode zurück­ge­grif­fen wer­den.

Sollte man den­noch ein­mal nicht um die AddFieldAsXML-Methode herum kom­men, dann sollte der DisplayName erst nach Hinzufügen des Feldes mit einem rich­ti­gen Wert (mit Leerzeichen, Umlauten usw.) ver­se­hen wer­den.

Related Posts

1 Kommentar

In der SPFieldCollection.AddFieldAsXml Method (String, Boolean, SPAddFieldOptions) kann man bei den SPAddFieldOptions den Wert SPAddFieldOptions.AddFieldInternalNameHint ver­wen­den. Dies führt dazu, dass der gege­bene interne Name ver­wen­det wird und nicht der InternalName aus dem DisplayName ermit­telt wird.

Comments are closed.

Pin It on Pinterest