© Kellie L. Folkerts/Shutterstock.com
Entwicklung clientseitiger SharePoint-Anwendungen mit zusätzlichen JavaScript-Bibliotheken

AngularJS und Knockout im Team


Eigene SharePoint-Erweiterungen benötigen oft serverseitigen Code und wurden in der Vergangenheit als Farmlösungen umgesetzt – mit all den bekannten Nachteilen. SharePoint 2010 führte zur Entschärfung der Probleme das Sandkastenmodell ein, das sich aber nicht durchgesetzt hat. Durch die Einführung des App-Modells in SharePoint 2013 gibt es nun eine gute Alternative zu reinen, voll vertrauenswürdigen Farmlösungen. Unter Zuhilfenahme des clientseitigen Objektmodells (CSOM) können ohne jeglichen serverseitigen Code umfangreiche Anwendungen nur mit HTML und JavaScript realisiert werden.

SharePoint kann dank seiner offenen Schnittstellen leicht um neue Funktionen erweitert werden. Zu den typischen und häufigsten Erweiterungen gehören eigene Webparts, Ereignisempfänger, Workflows, Menüerweiterungen, Apps und weitere Artefakte. Bis SharePoint 2010 wurden all diese Erweiterungen – ausgenommen Apps, die erst ab SharePoint 2013 möglich sind – als vertrauenswürdige Lösungen installiert und im bin-Verzeichnis oder im Global Assembly Cache (GAC) bereitgestellt. Dies bedeutet, dass fremder serverseitiger Code innerhalb des SharePoint-Prozesses zusätzlich ausgeführt wird, genauer gesagt im w3wp.exe des Internet Information Servers (IIS).

Verursacht eine zusätzlich eingebrachte Lösung eine Ausnahme (Expection), kann diese den gesamten SharePoint-Prozess gefährden. Fehler innerhalb einer eigenen Lösung stellen daher ein potenzielles Risiko für die Stabilität der SharePoint-Farm dar. Aber nicht nur die direkten Fehler können erhebliche Probleme verursachen. Weitaus schlimmer und oft schwieriger aufzudecken sind Speicherfehler, die durch die nicht korrekte Speicherfreigabe (Dispose) eines Objekts, wie etwa eines SPWeb-Objekts, entstehen können.

Aus diesen Gründen hat Microsoft versucht, zusätzliche Komponenten isoliert vom SharePoint-Prozess (w3wp.exe) zu betreiben. Aus diesem Versuch entstand das Sandkastenmodell, in dem Lösungen innerhalb eines eigenen Prozessraums ausgeführt werden. Das Sandkastenmodell hat sich allerdings aufgrund seiner Komplexität und Einschränkungen bei den Entwicklern nicht wirklich durchgesetzt. Durch seine Erweiterung um das App-Programmiermodell ermöglicht es SharePoint 2013 nun erstmalig, eigene SharePoint-Erweiterung vollkommen isoliert vom SharePoint-Serverprozess auszuführen.

Das App-Modell

Das App-Modell ermöglicht die vollkommene Isolation vom SharePoint-Prozess. Entweder verwendet eine App nur clientseitigen Code oder benötigter serverseitiger Code wird von einem externen Webserver ausgeführt. Die verfügbaren clientseitigen SharePoint-Bibliotheken (DLLs) erlauben es, alle relevanten API-Methoden auch entfernt zu verwenden, sei es von einem externen Webserver oder innerhalb eines Browsers.

Dieser Artikel konzentriert sich auf die Umsetzung clientseitiger Anwendungen, die ausschließlich auf JavaScript basieren. Somit benötigen diese Anwendungen keinen externen Webserver und können direkt vom SharePoint-Server bereitgestellt werden. Diese Art von Apps wird auch als SharePoint-hosted bezeichnet, da die Apps direkt vom SharePoint-Webserver ausgeliefert werden. SharePoint-gehostete Apps bestehen daher im Schwerpunkt aus HTML, CSS und JavaScript. JavaScript ist somit die einzig verfügbare Programmiersprache zur Abbildung eigener Abläufe und Interaktionen. Im Gegensatz zu anderen Programmiersprachen wie C# oder Java ist JavaScript etwas schwieriger zu strukturieren. Zudem kommt hinzu, dass viele Entwickler JavaScript noch als reine Skriptsprache ansehen. Diese beiden Umstände wirken sich negativ auf den implementierten Code aus, der somit oft unübersichtlich wird und eher an die Struktur eines Skriptprogramms erinnert.

Strukturierte JavaScript-Programmierung

Auch JavaScript besitzt Konzepte wie Klassen und Vererbung. Die Art und Weise der Verwendung unterscheidet sich jedoch von anderen objektorientierten Programmiersprachen. Um nicht selbst in die Tiefen der nativen JavaScript-Programmierung absteigen zu müssen, stehen Frameworks und Bibliotheken zur Verfügung, die eine strukturierte Umsetzung einer JavaScript-Anwendung ermöglichen. Die Verwendung solcher Frameworks und Bibliotheken bietet sich immer bei der Umsetzung größerer Anwendungen an. Der Code bleibt übersichtlich und ist später leicht erweiterbar. Zudem kann sich der Entwickler auf die eigentlich umzusetzende (Geschäfts-)Logik konzentrieren und muss sich nicht mit nativen JavaScript-Konzepten auseinandersetzen.

jQuery und Co.

jQuery ist eine sehr umfassende und seit langer Zeit bewährte JavaScript-Bibliothek. Im Kern erleichtert diese Bibliothek die DOM-Manipulation und kümmert sich dabei um die Cross-Browser-Kompatibilität. Neben der reinen DOM-Manipulation bietet jQuery natürlich noch zahlreiche weitere Funktionen und Erweiterungen. Im Grunde kann durch den Einsatz von jQuery schon sehr einfach eine umfangreiche Anwendung realisiert werden. Jedoch bietet diese Bibliothek kein Konzept im Sinne einer Anwendungsarchitektur oder eines Frameworks an. Die Daten und die Steuerung (Logik) der Anwendung liegen also weiterhin in verstreuten JavaScript-Funktionen. Um diese lose Verteilung besser zu strukturieren, ist ein Anwendungsframework notwendig. Hier kommt nun AngularJS zum Einsatz.

Strukturiert mit AngularJS

AngularJS ist ein von Google entwickeltes Framework für die Entwicklung komplexer clientseitiger Anwendungen [1]. AngularJS ist sehr umfangreich und ermöglicht die Definition eigener HTML-Tags und Attribute über so genannte „Directives“. Das Framework strukturiert eine Anwendung gemäß dem bekannten und bewährten Model-View-Controller-Design-Pattern. Darüber hinaus bietet der Einsatz von AngularJS folgende weitere Vorteile:

  • AngularJS-Anwendungen sind leicht erweiterbar.
  • Da gut strukturiert, bleiben auch komplexe Anwendungen gut zu warten.
  • AngularJS bietet eine eingebaute Unterstützung für Unit Tests.
  • AngularJS berücksichtigt Browserfunktionen.

AngularJS ist daher für die Realisierung clientseitiger SharePoint-Anwendungen ideal geeignet. Nachfolgend wird eine Beispielanwendung umgesetzt, die die wesentlichen AngularJS-Konzepte demonstriert und verdeutlicht, wie diese mit der clientseitigen SharePoint-JavaScript-Bibliothek interagieren. Als Beispiel wird eine SharePoint-gehostete App umgesetzt, die eine eigene Aufgabenliste beinhaltet. Die Listeneinträge werden über eine eigene Oberfläche bearbeitet.

Die Umsetzung der Anwendung startet wie immer mit der Anlage eines neuen Projekts in Visual Studio 2013. Als Lösungsvorlage kommt aus der Kategorie „Office/SharePoint-Apps“ die Vorlage „App for SharePoint 2013 Apps“ zum Einsatz. Der neuen App wird zunächst eine benutzerdefinierte Liste hinzugefügt, die auf der Listenvorlage „Aufgaben“ fußt. Abbildung 1 zeigt die definierte Liste.

Anschließend kann mit der Umsetzung innerhalb der Dateien default.aspx und App.js begonnen werden. Widmen wir uns zunächst der Startseite default.aspx. Damit AngularJS überhaupt funktioniert, besteht der erste Schritt darin, die notwendigen Bibliotheken einzubinden. Listing 1 zeigt die vollständig vorbereitete Startseite (aus Übersichtsgründen werden nur die beiden wesentlichen Platzhalter PlaceHolderAdditionalPageHead und PlaceHolderMain dargestellt). Dem Platzhalter PlaceHolderAdditionalPageHead wurden zwei JavaScript-Referenzen zu AngularJS hinzugefügt. Verwendet wird hier die Bibliothek, die über das CDN (Content Delivery Network) zur Verfügung steht. Bei Bedarf können die Bibliotheken natürlich auch heruntergeladen und lokal referenziert werden [2]. Die Datei angular.min.js enthält die grundlegenden Funktionen. Werden weitere Funktionen benötigt, müssen zusätzliche Module eingebunden werden.

zhou_angularjs_1.png

Abb. 1: Definierte Aufgabenliste

Da im weiteren Verlauf eine Navigation zu verschiedenen Ansichten (AngularJS Views) möglich sein soll, wird zusätzlich die Datei angular-route....

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