Warum SharePoint-Framework?
SharePoint wurde 2001 zunächst als lokales Produkt eingeführt. Im Laufe der Zeit hat eine große Entwicklercommunity es auf viele verschiedene Arten erweitert und gestaltet. Die Entwicklercommunity ist denselben Mustern und Methoden gefolgt, die das SharePoint-Produktentwicklungsteam verwendet hat, einschließlich Webparts, SharePoint-Feature-XML und mehr. Viele Features wurden als serverseitige Anpassungen mit C# geschrieben, in DLLs kompiliert und in lokalen Serverfarmen bereitgestellt.
Diese Architektur funktionierte gut in Umgebungen mit nur einem Unternehmen, konnte aber nicht für die Cloud skaliert werden, in der mehrere Mandanten nebeneinander auf den gleichen Servern ausgeführt werden. Dementsprechend haben wir zwei alternative Modelle eingeführt: clientseitige JavaScript-Einfügung und SharePoint-Add-Ins. Beide Lösungen haben Vor- und Nachteile.
Eines der beliebtesten Webparts in SharePoint Online ist der Skript-Editor. Sie können JavaScript in das Skript-Editor-Webpart einfügen, und dieses JavaScript dann beim Rendern der Seite ausführen. Es ist einfach & effektiv. Die Ausführung erfolgt im gleichen Browserkontext wie die Seite und befindet sich in der gleichen DOM, damit eine Interaktion mit anderen Steuerelementen auf der Seite möglich ist. Diese Methode ist recht leistungsfähig und einfach zu verwenden.
Dieser Ansatz hat jedoch auch einige Nachteile:
- Sie können Ihre Lösung zwar packen, sodass Endbenutzer das Steuerelement auf der Seite ablegen können, aber Sie können keine einfachen Konfigurationsoptionen bereitstellen.
- Der Endbenutzer kann die Seite bearbeiten und das Skript ändern, wodurch das Webpart unterbrochen werden kann.
- Das Skript-Editor-Webpart ist nicht als "Sicher für Scripting" gekennzeichnet. Die meisten Self-Service-Websitesammlungen (eigene Websites, Teamwebsites, Gruppenwebsites) haben ein Feature namens "NoScript" aktiviert. Technisch gesehen ist dies das Entfernen der Berechtigung „Add/Customize Pages“ (Hinzufügen/Anpassen von Seiten, ACP) in SharePoint. Dies bedeutet, dass das Skript-Editor-Webpart auf diesen Websites blockiert wird.
Eine Option für Lösungen, die auf NoScript-Websites ausgeführt werden, ist das Add-In-/App-Part-Modell, das mit SharePoint Server 2013 eingeführt wurde. Diese Implementierung erstellt einen iFrame, wo sich das eigentliche Objekt befindet und ausgeführt wird. Der Vorteil besteht darin, dass es für Information Worker einfacher ist, zu vertrauen und bereitzustellen, da der iFrame für das System extern ist und keinen Zugriff auf den aktuellen DOM/die aktuelle Verbindung hat. Endbenutzer können Add-Ins auf NoScript-Websites installieren.
Auch bei diesem Ansatz gibt es einige Nachteile.
- Sie werden in einem iFrame ausgeführt. iFrames sind langsamer als das Skript-Editor-Webpart, da es eine neue Anforderung für eine andere Seite erfordert. Die Seite muss die komplette Authentifizierung und Autorisierung durchlaufen, über eigene Aufrufe SharePoint-Daten abrufen, verschiedene JavaScript-Bibliotheken laden und vieles mehr. Ein Skript-Editor-Webpart braucht in der Regel z. B. 100 Millisekunden zum Laden und Rendern, während ein App-Part u. U. 2 Sekunden oder länger benötigt.
- Die iFrame-grenze erschwert das Erstellen reaktionsfähiger Designs und das Erben von CSS- und Designinformationen. iFrames verfügen über eine höhere Sicherheit, was für Sie nützlich sein kann (auf Ihre Seite kann von anderen Steuerelementen auf der Seite nicht zugegriffen werden) und für den Endbenutzer (das Steuerelement hat keinen Zugriff auf seine Verbindung mit Microsoft 365).
In der Vergangenheit haben Entwickler Webparts als voll vertrauenswürdige C#-Assemblys erstellt, die auf den Cloudservern installiert wurden.
Aktuelle Entwicklungsmodelle umfassen jedoch in der Regel JavaScript, das in einem Browser ausgeführt wird und REST-API-Aufrufe an die SharePoint- und Microsoft 365-Back-End-Workloads durchführt. C#-Assemblys funktionieren in dieser Umgebung nicht. Entwickler benötigten ein neues Entwicklungsmodell.
Das SharePoint Framework ist die nächste Stufe der SharePoint-Entwicklung.