SharePoint nutzt u.a. zur Speicherung von Daten Listen und Dokumentbibliotheken. Neben einigen vordefinierten Listen und Bibliotheken kann man auch benutzerdefinierte Listen erstellen und an die eigenen Bedürfnisse anpassen. Bei diesen benutzerdefinierten Listen kann man selbst festlegen, welche Spalten verwendet werden sollen und welchen Datentyp diese Spalten aufnehmen sollen. Und genau bei diesen Spalten bzw. den Namen der Spalten gibt es einiges zu beachten.

Wenn man eine neue Spalte in einer benutzerdefinierten Liste anlegen möchte, wechselt man in die Listen-Einstellungen und klickt dort auf 'Spalte erstellen'. Jetzt gibt man der neuen Spalte einen Namen und wählt einen Datentyp aus einer Liste vordefinierter Datentypen aus. Das sieht dann z.B. so aus, wie in diesem Screenshot dargestellt:

Auch wenn man der Spalte nur einen einzigen Spaltennamen zuweisen kann (was auf den ersten Blick auch logisch und völlig selbstverständlich erscheint), existieren neben dem Spaltennamen, den man beim Erstellen einer neuen Spalte vergibt noch zwei weitere Spaltennamen. Diese beiden zusätzlichen Spaltennamen bekommt ein SharePoint-User nur sehr selten zu sehen, ein Programmierer, der ein WebPart, einen Eventhandler, einen Workflow oder einen TimerJob programmiert, sollte aber schon sehr genau wissen, was es mit diesen zusätzlichen Spaltennamen auf sich hat.

Der Spaltenname, der beim Erstellen einer neuen Spalte angegeben wird, wird als Display Name bezeichnet. Wie dieser Name schon vermuten lässt, ist der Display Name der Anzeigename einer Spalte. Dies bedeutet: überall in der Oberfläche wo es um das Anzeigen von Daten und Informationen geht, wird der Display Name (Anzeigename) verwendet.

Beim Erstellen einer neuen Spalte erzeugt SharePoint (oder besser gesagt das unterlagerte Objekt-Modell) zwei weitere Spaltennamen: den Internal Name und den Static Name. Von diesen beiden Spaltennamen bekommt ein SharePoint-User kaum etwas zu sehen und auch ein SharePoint-Administrator oder ein Designer werden diese beiden zusätzlichen Spaltennamen nur selten zu Gesicht bekommen. Dennoch sind beide sehr wichtig und sollten besonders von Entwicklern beachtet werden.

• der Display-Name wird auch als Anzeigename bezeichnet und wird vom SharePoint-Benutzer beim Anlegen einer Spalte angegeben.
• der Static-Name wird von SharePoint beim Erzeugen einer neuen Spalte automatisch erzeugt.
• der Internal-Name wird ebenfalls von SharePoint beim Erzeugen einer neuen Spalte erzeugt.

Jetzt wissen wir, dass es nicht nur einen Spalten-Namen gibt, sondern drei - aber wozu braucht man denn drei Spaltennamen?

In erster Linie sind diese drei Spalten-Namen für Programmierer interessant. Da der Display-Name (also der Anzeigename) nachträglich verändert werden kann, besteht gerade für die Programmierung die Notwendigkeit, nicht-veränderliche Spaltennamen zu haben, um Spalten auch nach der Änderung des Display-Name noch identifizieren zu können. Beim Verändern des Display-Names werden weder Internal-Name noch Static-Name verändert, dennoch ist der Static-Name nicht ganz so unveränderlich, wie der Internal-Name. Im Gegensatz zum Internal-Name kann der Static-Name nachträglich über Aufrufe aus dem SharePoint Objekt-Modell verändert werden. Static-Name und Internal-Name müssen nicht zwingend gleich lauten.

• der Display-Name ist vom Benutzer direkt über die SharePoint-Oberfläche veränderbar und kann auch nachträglich beliebig oft umbenannt werden.
• der Static-Name bleibt beim Umbenennen einer Spalte unverändert, ist aber nicht wirklich unveränderbar. Über das Objekt-Modell kann der Static-Name verändert werden.
• der Internal-Name bleibt ebenfalls beim Umbenennen unverändert und kann auch über Objekt-Modell Aufrufe nicht mehr verändert werden.

Um den Static-Name zu ändern, reichen im Prinzip die folgenden Code-Zeilen:

   1: SPList oList = ... 

   2: string strColumnName = ...

   3:  

   4: oList.Fields.GetFieldByInternalName(strColumnName).StaticName = "NeuerName";

   5: oList.Fields.GetFieldByInternalName(strColumnName).Update(true);

Der Internal-Name scheint der wirklich eindeutige und unveränderbare Namen einer Spalte zu sein. Der Static-Name ist für die Programmierung interessant - ein Beispiel dafür ist die Webpart-Programmierung. Bei uns haben wir Richtlinien (oder neu-deutsch: Best Practices) erarbeitet, wie wir welchen Spaltennamen bei der Programmierung einsetzen. Wenn bei einem Webpart über die Webpart-Properties z.B. ein Spaltenname einer SharePoint-Liste angegeben werden soll, verwenden wir dafür grundsätzlich den Display-Name, um dem Designer die Arbeit der WebPart-Parametrierung zu erleichtern. Der Designer kann bei der Parametrierung eines WebParts die gleichen Spaltennamen eingeben, die er auch beim Anlegen der Liste verwendet hat.

Allerdings verwendet dann das eigentliche WebPart natürlich nicht mehr den in die Properties eingegebenen Display-Name, sondern wandelt diesen mit Hilfe der zugehörigen Liste in den Internal-Name. Intern arbeiten unsere WebParts grundsätzlich mit dem Internal-Name. Es hat für uns aber manchmal einen Vorteil, statt des unveränderlichen Internal-Name den nur bedingt unveränderlichen Static-Name zu verwenden. Dieser Vorteil wird deutlich, wenn wir das Thema Mehrsprachigkeit bzw. Variations betrachten. Angenommen wir haben zwei gleiche Listen - eine Liste mit deutschen Anzeigenamen und eine zweite Liste mit englischen Anzeigenamen. Mit beide Listen soll ein selbstprogrammierter Eventhandler verbunden werden (ein Beispiel dazu findet sich hier), der beim Beschreiben einer bestimmten Spalte getriggert werden soll. In diesem Fall würde der Eventhandler mit dem Static-Name der Triggerspalte arbeiten, denn der Display-Name wird sich aufgrund der unterschiedlichen Sprachen unterscheiden. Da der Static-Name zum Glück nicht vollständig unveränderlich ist, kann man -trotz unterschiedlichem Display-Name- den Static-Name nachträglich angleichen. Auf diese Weise kommt man mit einem Eventhandler für zwei sprachlich unterschiedliche Listen aus.

Wie ändert man denn nun den Static-Name einer SharePoint-Spalte, wenn dies nicht über die Oberfläche, sondern nur über das Objekt-Modell geht? Um dies zu zeigen, habe ich ein kleines Tool geschrieben, welches auf hier kostenlos zum Download (gegen eine kleine Registrierung) bereitsteht. Dieses Tool erlaubt die Auswahl eines Webs und einer Liste und zeigt die in der Liste vorhandenen Spalten mit ihrem Internal-Name an. Durch Anklicken einer Spalte kann man diese auswählen und dann ggf. Display-Name und Static-Name ändern. Man kann sich so einen schnellen Überblick über alle Spalten einer Liste verschaffen. Bei diesem Tool handelt es sich um ein Entwickler-Tool, welches wir intern bei unseren Entwicklungen nutzen. Für diesen Beitrag habe ich es ein wenig angepasst und aufgeräumt - dennoch bleibt es ein Entwickler-Tool und der Einsatz erfolgt grundsätzlich auf eigenes Risiko!

Bei der Programmierung bzw. bei der Verwendung des SharePoint Objekt-Modells muss man aber sehr aufpassen, welchen Spaltennamen man mit welcher Methode verwenden kann bzw. soll. Leider ist dies im SDK nicht einheitlich geregelt. Es gibt Methoden, bei denen schon aufgrund des Methodennamens klar ist, mit welchem Spaltennamen sie arbeiten: SPFieldCollection.GetFieldByInternalName(name) arbeitet wie der Name bereits andeutet, mit dem Internal-Name einer Spalte, während SPFieldCollection[name] den Display-Name verwendet. Bei SPListItem[name] wird die Sache noch etwas undurchsichtiger: hier sind alle drei Spaltennamen als Parameter erlaubt. Eine erste Übersicht von Methoden und deren Spalten-Parametern findet sich in diesem Blog.

Um zu zeigen, dass es nicht schwierig ist, bei der Programmierung die einzelnen Spaltennamen sauber zu trennen, hier ein kleines Snippet, wie man mit dem Display-Name den zugehörigen Internal-Name ermitteln kann.

   1: private string GetInternalColumnName(SPList oList, string strColumnDisplayName)

   2: {

   3:     string strRetParam = string.Empty;

   4:  

   5:     try

   6:     {

   7:         strRetParam = oList.Fields.GetField(strColumnDisplayName).InternalName;

   8:     }

   9:     catch

  10:     {

  11:         strRetParam = strColumnDisplayName;

  12:     }

  13:  

  14:     return (strRetParam);

  15: } 

Ich hoffe, dass ich mit diesem Beitrag zeigen konnte, wie wichtig es ist, gerade bei der Programmierung darauf zu achten, die unterschiedlichen Spaltennamen-Typen sauber zu trennen und sich vor Beginn der Programmierung zu überlegen, mit welchem Typ von Spaltennamen gearbeitet werden soll. Aus eigener Erfahrung kann ich sagen, dass es sehr aufwändig werden kann, Sourcecode zu debuggen, bei dem dauernd und scheinbar wahllos zwischen allen Spaltennamen-Typen gewechselt wird. Auch hier gilt: ein klar strukturiertes und durchdachtes Design macht das Programmieren und das Debuggen wesentlich einfacher!

Bisher habe ich erstaunlich wenige Blog-Posts zu diesem Thema gefunden - Grund genug für mich, meine eigenen Erfahrungen zu diesem Thema in meinem Blog zusammenzufassen.

Nachtrag: der Link zum kostenlosen Download unserer SharePoint-Tool geht im Text dieses Beitrags etwas unter. Deswegen hier nochmals der Link.