Custom Field Types sind eigentlich eine sehr praktische Sache wenn es darum geht, Eingaben benutzefreundlicher zu gestalten. Wie man ein Custom Field Type programmiert, dazu findet man im Internet zahlreichen Anleitungen und auch ich habe zuletzt auf der BASTA! Spring 2010 in einem Vortrag darüber und über mögliche Einsatzszenarien berichtet. Mit dem WSPBuilder (oder auch den Visual Studio Extensions) ist es wirklich keine große Sache mehr, ein Custom Field Type zu programmieren und in eine Solution zu verpacken.

Ich selbst verwende in meinen Kundenprojekten Custom Field Types sehr gern, um Listen mit Vorgabewerte (z.B. Dokument-Status, …) aus einem administrativen Web auszulesen und in Listen oder Bibliotheken anzuzeigen. Zu diesem Web haben dann nur wenige ausgewählte Mitarbeiter Zugang und können die Listen mit den Vorgabewerten pflegen.

Bevor man sich aber in der Planungsphase eines neuen Projektes allzu schnell auf die Verwendung von Custom Field Types festlegt, sollte man wissen, dass es neben den Vorteilen auch einige Nachteile (oder besser gesagt: Pitfalls) gibt, die man kennen muss.

1. Datenblatt-Ansicht

In den Forms (View, New, Edit) funktionieren Custom Field Types – aber leider funktionieren sie nicht in der Datenblatt-Ansicht. Normalerweise erreicht man diese Einstellung, wie im folgenden Screenshot dargestellt:

Zwar werden hier dann auch die Spalten dargestellt, denen ein Custom Field Type zugrunde liegt, aber diese Spalten können in dieser Ansicht nicht editiert werden. Beim Versuch, diese Spalten zu ändern oder zu beschreiben, bekommt man nur die Meldung, dass diese Spalten schreibgeschützt (read-only) sind.

Mit den Standard-Datentypen (z.B.: Choice) funktioniert es hingegen, wie erwartet. Bedeutet: die Auswahlen in einem Auswahlfeld werden in der Datenblatt-Ansicht angezeigt und auch als Auswahl dargestellt.

2. Microsoft Office Integration

Seit Microsoft Office 2003 gibt es eine SharePoint-Integration. Es ist damit möglich, Office-Dokumente direkt in eine SharePoint-Bibliothek zu speichern. Sind in dieser Bibliothek Pflichtfelder vorhanden, gibt Office eine enstrpechende Meldung aus und blendet den Document Information Panel ein. Bei Office 2003 war dies noch ein eigenes Fenster, aber ab Office 2007 wird der Document Information Panel unterhalb der Ribbon-Leiste eingeblendet. Hier kann  der Benutzer dann die fehlenden (Pflicht-)Felder ergänzen. Leider funktioniert dies nicht mit programmiertem Custom Field Types. Mit den Standarddatentypen (z.B. Choice) funktioniert die Office-Integration wie erwartet.

Zwar werden im Document Information Panel Custom-Field-Type-Felder angezeigt, aber nur als einfache Textfelder – selbst wenn diese Felder eigentlich z.B. als Listboxen dargestellt werden. Dies bedeutet, dass Custom Field Types bei der Office-Integration leider auch nicht unterstützt werden. Schreibt man in diese Textboxen, die eigentlich Custom Field Types ein sollten, beliebige Werte, dann werden diese Werte auch in die Bibliothek übernommen – auch dann, wenn die eingegebenen Werte überhaupt nicht in z.B. einer Listbox auftauchen. Dazu ein kurzes Beispiel: gehen wir davon aus, ein Feld wäre als Custom Field Type umgesetzt und würde die Werte (1,2,3,4) enthalten. Dieses Feld ist als Pflichtfeld markiert. Wenn man über die Office-Integration ein neues Dokument in die entsprechende Dokumentbibliothek speichert, kann man im Document Information Panel beispielweise den Wert 5 eingeben – dieser Wert wird übernommen, auch wenn er nicht in der Listbox auftaucht.

In obigem Bild sieht man oben (im blauen Teil) einen Teil des Document Information Panel (hier ist das Feld Firma ein reines Textfeld) und unten einen Auschnitt aus der SharePoint-Bibliothek (hier ist das Feld Firma ein Custom Field Type basierend auf einer Auswahl).

3. Webservice

Das bisher gesagte gilt leider auch für die Standard-SharePoint WebServices. Auch diese habe so ihre Probleme mit den Custom Field Types. Man kann zwar z.B. mit dem lists.asmx auf Listen oder Bibliotheken zugreifen, die selbstprogrammierte Custom Field Types enthalten, aber diese werden hier so wenig unterstützt, wie schon beim vorherigen Punkt (2. Microsoft Office Integration) geschildert.

4. Deployment

Custom Field Types werden normalerweise in eine Solution verpackt und in den Global Assembly Cache installiert. Dies sollte man auf jeden Fall berücksichtigen, denn nicht in allen Installationen ist dies möglich. Weiterhin werden Custom Field Types server-global installiert. Dies bedeutet: sie werden im Solution Management in der Zentraladministration als “globally deployed” dargestellt – und das ist in diesem Fall wörtlich zu nehmen. Laufen auf einem SharePoint-Server mehrere Web-Applications, dann ist der Custom Field Type in allen Web-Applications verfügbar und kann in allen Web-Applications genutzt werden. Dies sollte man unbedingt berücksichtigen, wenn man in einem Shared-Umfeld arbeitet. Nicht immer ist es sinnvoll bzw. gewünscht, dass ein Custom Field Type, der für WebApp_1 programmiert wurde, auf auf WebApp_2 sicht- und verwendbar ist!