Browsing all articles tagged with Development

JavaScript erfreut sich wieder immer größerer Beliebtheit, nicht zuletzt durch den neuen HTML5 Hype. In SharePoint Online bietet JavaScript, insbesondere in Kombination mit dem ECMA Client Object Model, uns gute Möglichkeit Limitationen von Sandboxed Solutions zu überwinden. Aber wie registriere ich JavaScripts richtig in SharePoint Online?

Probleme

In ASP.NET wird oft der ClientScriptManager benutzt um JavaScripts im Code Behind auf der Page zu registrieren. Das funktioniert aber leider nicht in einer Sandboxed Solutions. Obwohl uns zwar das Page Objekt im Code Behind eines WebParts zur Verfügung steht, haben jedoch Änderungen an diesem keine Auswirkungen auf das echte Page Objekt in ASP.NET. Der Grund hierfür ist, dass der Code von Sandboxed Solution nicht im IIS läuft, sondern im User Code Service und der simuliert lediglich den ASP.NET Page Life Cycle.

In SharePoint 2010 gibt es sogar extra die .NET Klasse ScriptLink um JavaScripts zu registrieren. Aber auch diese funktioniert nicht in Sandboxed Solutions.

Lösungen

Eine sehr einfache, aber nicht unbedingt elegante Möglichkeit JavaScripts global auszurollen besteht darin, die Master Page anzupassen und das Skript dort zu registrieren. Auch die in SharePoint 2007 sehr beliebten Delegate Controls stehen uns in Sandboxed Solutions leider nicht zur Verfügung.

Eine andere Möglichkeit ist das Skript innerhalb der Render Methode eines Webparts manuell zu registrieren. Hierbei sollte man aber darauf achten, dass das Skript nicht mehrfach zu laden wenn mehrere Instanzen eines WebParts auf einer Seite laufen. Genau hierfür bietet SharePoint eine sehr nützliche JavaScript Klasse namens SP.SOD (SharePoint Scripts on Demand, leider schlecht dokumentiert). Die Aufgabe von SP.SOD ist es Skripte bei Bedarf dynamisch zu laden. SharePoint selbst nutzt SP.SOD sehr intensiv und lädt viele JavaScript erst bei Bedarf dynamisch. Das hat den Vorteil, dass die Seite dem Benutzer schneller angezeigt wird und dann erst die Funktionalität (JavaScript) nachgeladen wird. Vielleicht ist auch dem ein oder anderen schon mal aufgefallen, dass die Ribbon Buttons erst kurz nach dem Laden der Seite aktiviert werden. Auch die oben erwähnte .NET Klasse ScriptLink macht im Hintergrund nichts anderes als serverseitig clientseitige SP.SOD Aufrufe zu generieren. Glücklicherweise steht uns SP.SOD auch in Sandboxed Solutions zur Verfügung. Jetzt genug Theorie, hier ein Beispiel.

Beispiel

myscript.js

image

Myscript.js registriert den Namespace “ilsp.scripts” und eine einfache “sayHello” Methode. Der letzte Aufruf teilt SP.SOD mit, dass das Skript mit dem Key “myscript.js” geladen wurde und dass eventuell vorhandene Callback Funktionen die auf myscript.js warten jetzt aufgerufen werden können.

Nun registrieren wir myscript.js mit Hilfe einer Custom Action.

image

In SharePoint 2010 kann man Scripts via Custom Action registrieren. Hierzu kann man entweder wie oben das ScriptBlock Attribut nutzen oder das ScriptSrc Attribut. Nachteil von ScriptSrc ist, dass man keine externen Scripts laden kann. Das Script muss entweder im Layouts Ordner liegen (nicht möglich in Sandboxed Solutions!) oder innerhalb der SharePoint Site (kann über ein Modul bereitgestellt werden). Des Weiteren kann man die Scripts nicht “On Demand” laden. In SharePoint Online lade ich Script Libaries gerne aus dem Azure Blob Storage. Hierdurch kann das Script nachträglich leicht, zentral gewartet werden. RegisterSod lädt das Script nicht direkt sondern registriert es lediglich zum späteren laden, sofern benötigt.

Als nächstes Erstellen wir ein Sandboxed Visual Webpart.

image

image

In sayHelloClick wird durch LoadSodByKey das bereits registrierte myscript.js dynamisch geladen. Dynamisch geladen bedeutet, dass der entsprechende Script Tag dynamisch erstellt und zum HTML Head Element hinzugefügt wird. Die Callback Funktion im zweiten Parameter wird nur aufgerufen wenn das Script initial geladen wurden. ExecuteOrDelayUntilScriptLoaded wartet bis ein Script fertig geladen wurde (SP.SOD.notifyScriptLoadedAndExecuteWaitingJobs) und ruft dann die definierte Callback Methode auf.

Ablauf

Bei jedem Laden einer Seite wird myscript.js als SOD registriert aber noch nicht geladen (alert: Register SOD).

Erst wenn “Say Hello” zum ersten Mal geklickt wird, wird myscript.js geladen und dann ilsp.scripts.sayHello aufgerufen (alerts: Loading Scripts…; Notify Script Loaded; Hello Thorsten!).

Beim zweiten klick wird myscript.js nicht nocheinmal geladen, sondern nur noch ilsp.scripts.sayHello aufgerufen (alerts: Hello Martina!)

Hört sich verwirrend an? Ist es auch clip_image001

(…weitere Details zu SP.SOD findet Ihr auch auf meinem Blog.)

Wir bleiben noch etwas im Sandkasten (in den Thorsten mittlerweile schon ein paar Löcher gebohrt hat ;) und werfen einen Blick Sandboxed Workflow Actions. Seit SharePoint 2007 besteht die Möglichkeit SharePoint um eigene Workflow Actions zu erweitern. Allerdings musste man die Actions Farm-weit zur Verfügung stellen. In SharePoint 2010 können wir jetzt auch Workflow Actions via Site Collection Feature bereitstellen. Dies gilt sowohl für Farm Solutions als auch für Sandboxed Solutions. Mit Hilfe einer Sandboxed Solution können wir custom Workflow Actions auch einfach in Office 365 bereitstellen. Die Programmierung einer Sandboxed Workflow Action funktioniert etwas anders als die einer Farm Solution. Im folgenden Post werde ich anhand einer “Create Site Action” zeigen wie man Sandboxed Workflow Actions selbst schreiben kann.

1. Neues leeres SharePoint Projekt in Visual Studio erstellen

2. Sandboxed Solution auswählen

3. Site Collection Feature anlegen (Workflow Actions sollten immer in ein eigenes Feature und nicht mit anderen Feature-Elementen vermischt werden. Es kannst sonst zu Problemen kommen=>Feature-Element-Gulasch)

4. Empty Element hinzufügen und das XML wie folgt bearbeiten:

image_thumb[35]

SandboxedFunction=”true” teilt der Workflow Infrastructure mit, dass es sich um eine Sandboxed Action handelt. FunctioName verweist auf die entsprechende Methode in der Implementierung. Das Element RuleDesigner beschreibt die UI in SharePoint Designer und mapped UI Felder mit Hilfe des Field Attributes auf die Parameter. Die verfügbaren DesignerTypes findet man hier. Die Parameters Elemente binden die Parameter an die Parameter und den Rückgabewert der Methode der Implementierung.

5. Die Implementierung der Create Site Action

image_thumb[36]

Der Name der Methode muss dem FunctionName Attribut des Element Manifest entsprechen (grün). Die Parameter der Methode entsprechen den Direction=”In” Parametern des Manifest (orange). Einzige Ausnahme ist der interne Parameter “___Context” bei dem die Unterstriche fehlen. Die Keys der Hashtable entsprechen den Direction=”Out” Parametern des Manifests (rot).

6. Sandboxed Solution hochladen in der Solution Gallery hochladen und das Site Collection Feature aktivieren

7. Workflow bauen

SNAGHTML1d5d65a_thumb[6]

image_thumb[41]

ENDE

Download

Hinweis zum Kommentar

Zum Kommentieren der Beiträge (und damit zur Teilnahme am Gewinnspiel) bitte auf die Zahl in der Bubble neben dem Titel des Blogeintrags klicken, dies öffnet das Kommentarformular!

Sponsored by

Subscribe

Über

Der SharePoint Advent

Ein Gemeinschaftsprojekt der deutschsprachigen SharePoint MVP's

Rubriken

Impressum

(c) 2011 SharePointCommunity