© Kellie L. Folkerts/Shutterstock.com
Einführung in das SharePoint Framework (Teil 3)

Kolumne: SharePoint ganz praktisch


Nachdem in der vorigen Kolumne die Verwendung von Knockout als clientseitiges Framework erläutert wurde, soll es in diesem Teil zunächst um das neue SharePoint Framework (kurz: SPFx) gehen. Es ist seit 2017 verfügbar und bietet eine neue Möglichkeit für die Realisierung von SharePoint-Lösungen.

Wie im vorherigen Teil deutlich wurde, ermöglicht Knockout in Kombination mit dem clientseitigen Objektmodell eine schnelle und saubere Umsetzung von SharePoint-Add-ins. Analog zum Einsatz von Knockout kann auch Angular verwendet werden. Die generelle Vorgehensweise für die Umsetzung des eigentlichen SharePoint-Add-ins ändert sich dabei nicht. Daher widmen wir uns an dieser Stelle zunächst dem sogenannten SharePoint Framework. Das mit SharePoint 2016 neu verfügbare Entwicklungsmodell ermöglicht die Anpassung der SharePoint-Oberfläche auf eine neue Art und Weise; erstmals sind auch Entwickler, die nicht im SharePoint- und/oder .NET-Umfeld tätig sind, in der Lage, SharePoint-Erweiterungen zu realisieren. Das SharePoint Framework ermöglicht die Realisierung sogenannter voll vertrauenswürdiger clientseitiger Web Parts, die vollständig in das SharePoint-UI – also direkt in das HTML-DOM – eingebunden sind.

Warum ein neues Entwicklungsmodell?

Das mit SharePoint 2013 eingeführte Entwicklungsmodell für SharePoint-Add-ins (vormals: SharePoint Apps) ist auch weiterhin in SharePoint 2016 verfügbar. Das neue SharePoint-Framework-basierte Entwicklungsmodell kann parallel zu den vorhandenen Entwicklungsmodellen verwendet werden. Interessanterweise wurden mit den letzten drei neuen SharePoint-Versionen auch jeweils neue Entwicklungsmodelle eingeführt. Mit SharePoint 2010 hielten die sogenannten Sandkastenlösungen Einzug in die SharePoint-Welt. Seit SharePoint 2013 können Add-ins realisiert werden, und mit SharePoint 2016 gibt es nun ein weiteres Lösungsmodell. Es gibt zwei Gründe, warum verschiedene Modelle entwickelt wurden: Zum einen ist eine fehlende Akzeptanz der Entwicklergemeinde zu beobachten, zum anderen gibt es funktionale Einschränkungen. SharePoint-Entwickler haben sich mit der Umsetzung von Sandkastenlösungen immer schwer getan und vorzugsweise voll vertrauenswürdige Lösungen realisiert. Zudem stehen bei den Sandkastenlösungen nicht alle SharePoint-API-Möglichkeiten zur Verfügung oder müssen umständlich per Proxy verfügbar gemacht werden. Auch SharePoint-Add-ins bringen wegen des notwendigen Bereitstellungsprozesses weitere Hürden mit sich, die überwunden werden müssen, bevor mit der Umsetzung der eigentlichen Lösung begonnen werden kann. Der wesentliche Nachteil von SharePoint-Add-ins – der technologisch eigentlich ein Vorteil ist – liegt in der vollständigen Isolation gegenüber SharePoint. Microsoft hat bisher mit allen Entwicklungsmodellen versucht, die direkte Einbindung von fremden (kundenspezifischen) Codes zu unterbinden. Damit sollte vermieden werden, dass der SharePoint-Server bei der Ausführung von fremdem Code negativ beeinflusst wird. Mit dem SharePoint-Add-in-Modell wurde dieses Ziel erreicht: Es wird keinerlei serverseitiger Code auf dem SharePoint-Server ausgeführt, und clientseitig findet eine Integration der Benutzeroberfläche über die Einbindung eines iFrames statt. Die iFrame-Einbindung stellt allerdings ein großes Problem für responsive Websites dar, die auf verschiedene Geräte und Auflösungen hin optimiert sind. Die Größensteuerung und die flüssige Einbindung von Inhalten über ein iFrame sind nicht vernünftig möglich.

Script Editor Web Part

Um dieses Problem zu umgehen, verwenden SharePoint-Entwickler gerne das Script Editor Web Part. Mit dessen Hilfe kann sehr einfach direkt ein eigener Skriptcode (JavaScript...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang