In diesem Artikel möchte ich zwei Technologien vorstellen und gegenüberstellen, die mir in diversen SharePoint-Projekten sehr geholfen haben. Sowohl das Tag Mapping als auch die Control Adapter sind von der Idee her dafür vorgesehen, bestehende Controls in einer Webseite nachträglich auszutauschen. Dennoch gibt es unterschiedliche Anwendungsfälle für beide Ansätze.

Ein Szenario für den Einsatz von Control Adaptern oder Tag Mapping könnte in der Praxis wie folgt aussehen:

Ein Kunde hat ein fertiges Portal implementiert, welches in der Regel keine eigenen Komponenten verwendet sondern Controls vom Hersteller (bspw. Microsoft) oder von Drittanbietern. Nun kommt ein weiterer Aspekt zum Portal hinzu, der vorher nicht berücksichtigt wurde. Dieser Aspekt kann bspw. Barrierefreiheit oder eine minimale, kundenspezifische Anforderung sein, die die bestehende Komponenten nicht hergeben.

Ich möchte nachfolgend auf beide Ansätze eingehen, ihre Anwendungsfälle zeigen und Vor- bzw. Nachteile darstellen.

 

Control Adapter

Der Control Adapter-Ansatz, ist immer dann relevant, wenn das neue Control, welches das bestehende ersetzen soll, grundlegend anders arbeitet und in der Regel nicht von dem bestehenden erbt. Der Control Adapter wird vom IIS anstelle des eigentlichen Controls gerendert. Dabei kann der Vererbungs-Aspekte, wie bspw. das Überschreiben von Methode der Basisklasse des bestehenden Controls nicht genutzt werden.

Bei dem Control Adapter-Ansatz wird in der .browser-Datei ein Mapping-Eintrag zwischen bestehenden Control und dem Control Adapter eingetragen. Der Control Adapter kann u.a. die  Ausgabe des Controls abfangen, aufbereiten und an Stelle des Controls rendern.     

image

Vorteile

– Es bedarf keinerlei Abhängigkeiten zwischen dem Control und dem Control Adapter. Hoher Freiheitsgrad

Nachteile

Den Eintrag in der .browser-Datei programmatisch einzufügen ist relativ aufwändig.
– Die Performanz wird durch Control Adapter gering negativ beeinflusst.

Tag Mapping

Das Tag Mapping ist dann interessant, wenn ein bestehendes Control durch ein neues ersetzt werden soll, welches von dem bestehenden erbt oder beide Controls die selbe Basis-Klasse haben.

Kürzlich hatte ich den Fall, dass ein Kunde den out-of-the-box People Picker von SharePoint 2010 gegen eine eigene Komponente austauschen wollte, um den Funktionsumfang zu erweitern. Der kundenspezifische People Picker erbt von der Standard-Komponente und überschreibt lediglich eine Methode, um einen Account zu validieren. Für dieses Szenario war das Tag Mapping der ideale Ansatz.

Beim Tag Mapping wird ein Mapping-Eintrag direkt in der web.config eingetragen. Dieser kann bspw. wie folgt aussehen:

<pages>
      <tagMapping>
         <add
            tagType=
               "System.Web.UI.WebControls.WebParts.WebPartManager"
            mappedTagType=
               "Microsoft.Sharepoint.WebPartPartManager, 
                MSPS.Web.dll, Version='2.0.0.0'" 
         />
      </tagMapping>
   </pages>

Ein Tag Mapping-Eintrag kann für ein SharePoint-Projekt mit einer SPWebConfigModification relative problemlos in alle web.config’s eintragen werden.

Vorteile

– Wenn das neue Control von dem bestehenden erbt, kann out-of-the-box Funktionalität ideal erweitert werden.
– Der Tag Mapping-Eintrag kann relativ schnell und komfortabel in der web.config eingefügt werden.
– Die Performanz ist besser als bei dem Control Adapter-Ansatz.

Nachteile

– Geringere Freiheitsgrade: Das neue Control muss – für eine ideale Integration in das bestehende System – von dem bestehenden Control erben oder die gleiche Basisklasse haben.  
– Performanz-Einbußen sind da, aber kaum relevant.

 

Fazit

Beide Ansätze sind ungemein hilfreich, um bestehende Komponenten nachträglich auszutauschen. Welcher Ansatz der richtige ist, hängt  von den Anforderungen ab. Soll eine bestehende Komponente lediglich erweitert  werden, dann ist das Tag Mapping ideal. Soll eine bestehende Komponente gegen eine ganz neue ausgetauscht werden, die funktional keine Abhängigkeiten zu der bestehenden hat, ist der Control Adapter das Mittel der Wahl.

Ich hoffe Ihr könnt im nächsten Projekt einen der beiden Ansätze für Euch nutzen!

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.