Seit SharePoint 2013 existiert nun eine Rendering-Technologie, die auf JavaScript basiert. Sie ist weitläufig als JS Link bekannt. Dieser Artikel soll einen kurzen Einblick in die Technik geben und stellt diese dem alt bewährten XSL-Verfahren gegenüber.

In SharePoint 2010 wurde eine Anpassung der dargestellten Listeninhalte bisher oftmals mithilfe von XSLT durchgeführt. Die auf XML basierende Metasprache bot dem Designer eine Möglichkeit zur Anpassung der Darstellung von Daten. Hierbei machte es keinen Unterschied, ob es sich um einen Listentitel oder aber reine Inhalte handelte. Um ein Design anzupassen, wurde ein Konstrukt wie in Listing 1 verwendet. Dieses Stück Quelltext wurde in einer XSL-Datei auf dem Server hinterlegt und in der entsprechenden Liste angewandt. Das Ergebnis ist eine modifizierte Darstellung der Ergebnisse.

Das Template wurde oftmals über einen externen Editor erstellt bzw. bearbeitet, im Idealfall war er mit einer kleinen Syntaxprüfung ausgestattet. Dies ist jedoch keine Garantie dafür, dass das Template auch seine Funktion erfüllt. Fehler konnten in der Regel nur über das ULS-Log oder über das Frontend geprüft werden, darauf hatten Designer allerdings fast nie direkten Zugriff. Somit blieb hier nur die übliche Try-and-Error-Prozedur, um irgendwann einmal das gewünschte Ergebnis zu erzielen.

<xsl:template name="MyTemplate" match="Row[@Style='Kachel']"  mode="itemstyle">
  <div>
    <h3><xsl:value-of select="@Title" /></h3>
</div>
</xsl:template>

Listing 1: Minimales Beispiel für ein benutzerdefiniertes Template mit XSLT

Des Weiteren wird die komplette Darstellung auf dem Server vorbereitet und fertig an den Server übermittelt. Besaß ein XSLT rechenintensive Funktionen, hatte dies zur Folge, dass die Darstellung sehr träge wurde und den Server unnötig belastete.

Client-side Rendering – JS Link

Mit der neuen SharePoint-Version hat Microsoft nun eine weitere Rendering-Technologie basierend auf JavaScript hinzugefügt. Oftmals wird diese Technik als Client-side Rendering (CSR) oder JS Link bezeichnet, in diesem Artikel wird der Name JS Link verwendet.

JS Link verlagert das Darstellen der Elemente vom Server zum Client und nutzt somit die Rechenleistung der Clients. Zudem besteht hierbei die Möglichkeit, auch externe Bibliotheken, (beispielsweise jQuery) einzubinden, die das Potenzial enorm erweitern. Eine Dokumentation dessen ist unter [1] und [2] zu finden.

Der direkte Vergleich

Listing 2 und Listing 3 stellen die gleiche Funktionalität dar. Es wird jeweils der Inhalt eines Felds (XSLField) ausgegeben, der wiederum jeweils um die Bezeichnung „Inhalt-“ erweitert wird. Schnell wird ersichtlich, dass JS Link bereits jetzt verständlicher, schlanker und intuitiver wirkt.

<xsl:template name="MyTemplate" match="FieldRef[@FieldType='XSLField']" mode="Text_body">
  <xsl:param name=”thisNode” select="."/>
<span>
  <b>Inhalt-</b>
  <xsl:value-of select="$thisNode/@*[name()=current()/@name] "/>
</span>
</xsl:template>

Listing 2: Beispiel Auszug XSLT

Function RenderJSLinField(ctx)
{
  var ret=[];
  ret.push("<span><b>Inhalt-</b>");
  ret.push("ctx.CurrentItem[ctx.CurrentField.Name].toString());
ret.push("</span>");
return ret.join('');
}

Listing 3: Beispiel Auszug JS Link

Vorteile von JS Link

Die Vorteile von JS Link lassen sich in drei Punkten zusammenfassen:

• Performance: Die Darstellung bzw. das Rendern der Inhalte wird vom Server- zum Clientrechner verlagert. Somit ist der Server damit nicht länger belastet.
• Einfach zu entwickeln: Jeder Webentwickler ist mit JavaScript vertraut, weshalb keine Einstiegsschwierigkeiten bestehen sollten. Zudem verkürzt sich mithilfe von JS Link die Entwicklungszeit.
• Flexibilität: Man kann entscheiden, ob nur ein Feld, die Kopf- bzw. Fußzeile oder die komplette Ansicht überschrieben werden soll. Ebenso können zusätzlichFrameworks wie jQuery o. Ä. verwendet werden, womit das volle Potenzial ausgeschöpft werden kann.

Nachteile von JS Link

Doch die Technologie beherbergt auch Nachteile:

• Kompatibilität: Bei der Entwicklung muss stetig beachtet werden...