Mehr Spaß mit TypeScript: Klassenschnittstellen

Man kann in TypeScript ja über die new() Funktion Konstruktoren insbesondere auch in Schnittstellen referenzieren. Schauen wir uns dazu einmal folgendes Beispiel an:

interface IAnyFactory<TAny> {
new (param: string): TAny;
greeting: string;
}

class Any {
static greeting = "Hi";
constructor(private _param: string) {}
}

function create<TAny>(factory: IAnyFactory<TAny>): TAny { return new factory("test"); }
function testAny(): Any { return create(Any); }
Ich kann an die Funktion create erst einmal irgendeine Klasse übergeben, wo dann tatsächlich der Konstruktor als Parameter verwendet wird. Alle statischen Felder und Methoden einer Klasse sind aber in JavaScript einfach nur die Eigenschaften dieser Funktion. Über die Schnittstelle IAnyFactory verlangt create, dass nur solche Klassen verwendet werden dürfen, die zusätzlich auch ein statisches Feld greeting der Art string haben. Ich kann mir vorstellen, dass dieses Verhalten ganz praktisch sein kann: man hat hier quasi so etwas wie eine Schnittstellendefinition für eine Klasse!

Happy Coding

Jochen

CoffeeBreak – Nachschlag zum Fazit

Nur so als kleiner Abschluss zum vorläufigen Fazit:

  • JOIN funktioniert wie dokumentiert
  • Eindeutige Schlüssel gehen wie im Internet beschrieben, die Dokumentation scheint mir aber unvollständig zu sein (EnforceUniqueValues im CAML)
  • Ein Pflichtfeld (Required TRUE) habe ich nicht hinbekommen: über JSOM kann man auch Items ohne Wert einspielen

Ich denke, dass war es für diese Evaluation – vielleicht irgendwann einmal mehr.

Jochen

CoffeeBreak – Gruppierung und Aggregation

Und es geht natürlich doch direkt aus JSOM heraus – ein erstes Sorry an SharePoint! Schickt man ein geeignetes View XML an renderListData einer Liste, dann erhält man alle gewünschten Aggregationen – alle Zahlen zwar als Zeichenketten, aber wenn man das weiß ist das mit einem parseFloat schnell erledigt [naja: modulo kleiner LCID Missverständnisse zwischen Client und Server, produktiv wäre da noch nicht das letzte Wort gesprochen]. In der Evaluation passiert das so:

  • Der Controller setzt die Suche mit der eigenen Klasse und group() sowie aggregate() auf
  • In der SharePoint Schnittstelle wird dann das daraus erzeugte View XML in pivot() genutzt
  • Die Ergebnisklasse extrahiert die gewünschten Aggregationen

Na also…

Jochen

CoffeeBreak – Ein kleines Fazit

Angefangen hat es mit der Lektüre von Inside Microsoft SharePoint 2013 – insgesamt eine recht gute Übersicht mit auch einigen Vertiefungen und dass mein Interesse am Ende etwas nachgelassen hat liegt vermutlich an den Themen. Es beantwortet sicher nicht alle Fragen, macht aber Lust auf mehr. Da das Thema SharePoint AddIn für mich neu war habe ich mir überlegt, mir mal die Entwicklung eines solchen AddIns an einem (Pseudo-) praktischen Beispiel anzuschauen. Natürlich wollte ich auch noch mal einige Themen wie Listen, Felder, Content Types etc. auffrischen – ja, es gibt seit WSS 3.0 Neues, aber wirklich anders ist es ja nicht: selbst die Art der SQL Datenbankablage ähnelt noch der Urform.

Diese Fokussierung ist auch einer der Gründe warum die folgenden Aussagen mit Vorsicht zu genießen sind, da sie auf gefährlichem Halbwissen basieren. Ich denke zwar, dass ich vielleicht das eine oder andere noch vertiefen werden (Join und GroupBy vor allem), aber im Grund ist mein selbst gesetztes (Zeit-)Budget für die Evaluation erschöpft. Schauen wir mal.

Am Anfang habe ich sehr viel die Visual Studio Assistenten zum Anlegen von Listen, Feldern und Content Types verwendet. Allerdings fand ich immer wieder Aufgaben, die dann doch nur in der XML erledigt werden konnten und hatte Änderungen in der XML vorgenommen, die der Assistent dann beim nächsten Speichern stillschweigend wieder entfernte. Die zweite Liste wurde dann sogar in ein zweites Feature eingefügt, was mich dann eine Zeit beschäftigt hat bis ich herausgefunden habe, dass deswegen ein Lookup Feld nicht funktionierte. Erstes Fazit daher: CAML lernen und direkt die XML Datei pflegen – tatsächlich nimmt der Assistent nicht wirklich viel Arbeit ab (Mindestens allerdings diese Ausnahme: alle Felder eines existierenden Content Types zur Liste hinzufügen).

Die Liste mit den Arten der Kaffeesorten sollte den Titel eigentlich als eindeutigen Schlüssel haben – im Client wird das zwar beim Anlegen geprüft, aber das passiert nur im Client Code und ist nicht Multi-User-sicher. Auch wenn das wohl inzwischen bei SharePoint Out-Of-The-Box geht habe ich darauf erst einmal verzichtet – ein Punkt den ich mir noch einmal anschauen muss: geht das auch auf dem vordefinierten Feld Title, kann man die Fehlermeldung beim Speichern auch über JSOM eindeutig identifizieren, etc.

Auch mein Lookup Feld (eine Spende referenziert genau eine Art von Kaffee) ist etwas halbherzig. Zwar unterstützt die kleine Anwendung selbst weder Löschen noch Ändern von Spenden und Arten, aber über den Direktaufruf der Listen (Lists/CoffeeTypes und Lists/Donations) geht das dann doch – ich habe glücklicherweise noch nicht herausgefunden, wie man den externen Zugriff dieser URLs gänzlich sperrt. Und das Löschen einer Kaffeesorte hinterlässt Spenden mit offenen Referenzen – laut Dokumentation soll dies aber konfigurierbar sein, daher bin ich dem nicht weiter nachgegangen. Das ist aber auch nur eine kleine Spitze eines Eisbergs: SharePoint scheint es grundsätzlich egal zu sein, ob ein Feld Required (TRUE) ist: speichern kann man irgendwie immer. Offenbar nur ein Hinweis für Formulare?

Eigentlich wollte ich das Lookup gar nicht sondern mal schauen, wie man ein Join zwischen zwei Listen in einer CAML Suche formuliert und auswertet. In der Dokumentation ist das ziemlich klar aber leider war die Zeit am Ende – vielleicht später einmal. Lookup Felder sind aber durchaus handlich, daher habe ich hier auch nicht mehr verstärkt gesucht.

Interessant war auch mein Versuch eine CAML Suche auf eine Liste Gruppieren zu lassen. Tatsächlich ist mit das nicht wirklich gelungen, herausgekommen ist nur so eine Art Sortieren: Elemente mit gleichem Wert stehen zusammen. Der Dokumentation nach geht ein echtes Gruppieren (mit Aggregation, in diesem Fall bräuchte ich ein Count() und ein Sum()) nicht mit reinen CAML Suchen sondern nur über Listen. Das kann ich mir noch nicht wirklich vorstellen, hier muss ich sicher noch einmal nachhaken. Wenn dem so ist, wäre das übel, wie man an der implementierten Lösung sieht: der Client liest alle Elemente und gruppiert selbst! Mit wachsender Anzahl von Elementen ein potentielles Performance Problem und ich würde so etwas niemals produktiv freigeben.

Die Gruppierung selbst habe ich über ein berechnetes Feld gemacht, das wiederum sehr einfach einzurichten war. Die Dokumentation der Formelsprache ist aber recht dürftig – zumindest bei Microsoft, oder ich habe mal wieder falsch gesucht. Um die App überhaupt mit einer Gruppierung nach Zeit testen zu können wird hier eine Granularität nach Minuten verwendet – realistisch wäre wohl eher nach Tag, das kann man mit der aktuellen Implementierung einfach durch Umkonfiguration des Feldes erreichen.

Nimmt man nun noch das Problem hinzu, dass SharePoint-Hosted AddIns bei der Deinstallation die Daten in den privaten Listen verlieren, dann bin ich mir nicht ganz sicher, ob das von mir überlegte Beispiel tatsächlich realistisch ist. Im Moment würde ich diese Technologie für Apps nutzen, die auf bestehenden Daten (Listen auf Site Ebene oder höher, die in das App Web hinein sichtbar sind) Zusatznutzen anbieten. Ansonsten reicht eine App evtl. alleine nicht aus. Auf der positiven Seite ist allerdings ganz klar zu sagen: mit den für andere HTML5/JavaScript verwendeten Techniken und Visual Studio lassen sich auch SharePoint Apps prima entwickeln, ohne sich auf das nackte CSS und JavaScript beschränken zu müssen.

Puh, reicht erst mal.

Aber vielleicht reicht dem einen oder anderen das wirre Zeugs hier für einen eigenen schnellen Einstieg in eine Evaluation!

Jochen

CoffeeBreak – Über die Entwicklungsumgebung

Entwickelt man heutzutage HTML5 / JavaScript Anwendungen dann ist man (irgendwie jeder für sich) an eine gewisse Entwicklungsumgebung gewohnt. Nach dem Erstellen des SharePoint AddIn Projektes in Visual Studio 2015 (Update 3) fehlte mir doch einiges zur Comfort Zone, das ich mir dann entsprechend eingerichtet habe.

Natürlich ist da erst einmal TypeScript – als Ergänzung zu JavaScript. Vielleicht habe ich da nicht richtig gesucht, aber Microsoft direkt scheint da nichts anzubieten. Ich habe daher im Projekt nur die Definitely Typed Definitionen verwendet. Zwar gibt es doch so einige Anwender mit TypeScript Bibliotheken zum Zugriff auf SharePoint, aber ich habe das Ganze hier minimalistisch gehalten und das Notwendigste selbst implementiert – vielleicht ein Ausgangspunkt für eine Bibliothek, vielleicht aber auch nur Ideen, die anderswo schon so umgesetzt sind und die ich einfach nur nicht gefunden habe. Auch der Start der Anwendung erfolgt natürlich in einer TypeScript Klasse – mit einem kleinen Tweak für den Unterschied zwischen Stand-Alone Betrieb und Integration als Client Web App.

Aus den einzelnen TypeScript Dateien wird eine einzige JavaScript Datei erstellt, die dann im Package der App landet – für alle TypeScript Dateien habe ich den Deployment Type auf NoDeployment gesetzt, da die nichts auf dem produktiven System zu suchen haben.

Zur Pflege der CSS Dateien verwende ich im Allgemeinen SASS, hier im Projekt via NodeJS und Gulp eingerichtet – will man das Projekt übersetzen, muss einmalig ein NPM UPDATE machen, ich habe darauf verzichtet das Modulverzeichnis auf GitHub hochzuladen. Tatsächlich war das hier ein absoluter Nebenschauplatz und auf Styling habe ich weitestgehend verzichtet – die SASS Datei ist minimal und da ist sicher eine Menge Luft nach oben. Kritisch ist vor allem, dass ich die SharePoint Umgebung weitestgehend ignoriere (die ASPX des Client Web Parts wurde entsprechend reduziert und referenziert nicht das Styling der Seite) darum sieht die Anwendung doch etwas eigenartig aus – naja, die Alternative wäre die Einarbeitung in die SharePoint Konventionen, was ich mir hier erst einmal ersparen wollte.

Die Anwendung ist als Single-Page-Application (SPA) angelegt, ich habe auf ein explizites Binding Framework wie AngularJS verzichtet und die paar Bindungen explizit (und meiner Ansicht nach auch klarer als die $watch-Magie von AngularJS 1.5) vorgenommen. Als externe JavaScript Bibliotheken sind lediglich (die heute 🙂 gerade) aktuelle Versionen von jQuery und jQueryUI über das in Visual Studio integrierten NuGet eingebunden – auch diese Pakete sind nicht auf GitHub und vor dem eigenen Übersetzen des Projektes muss einmalig ein Restore aus Visual Studio heraus ausgeführt werden. Die Programmierung gegen diese Bibliotheken erfolgt natürlich über die Definitely Typed Definitionen aus TypeScript heraus.

Mit diesen kleinen Vorbereitungen lässt sich das SharePoint-Hosted AddIn fast wie ein normales HTML5 / JavaScript Projekt entwickeln und auch gegen eine virtuelle Maschine (Windows Server 2012 R2 – etwas tricky in der Einrichtung der SharePoint Foundation 2013 aber zumindest alles wesentliche bekommt man ans Laufen) debuggen – sowohl Stand-Alone als auch als Client Web Part.

Die Struktur der Anwendung entspricht so ganz grob einem MVC Ansatz, richtig sauber war ich da aber nicht:

  • Zur Anzeige wird ein Controller und ein passender View erzeugt
  • Der Controller erstellt und verwaltet das Modell
  • Die Kommunikation des Controllers mit seinem Umfeld erfolgt ansonsten über eine Präsentationsschnittstelle
  • Aus Faulheit wird diese aber direkt vom View implementiert
  • Der View bindet sich geeignet an die HTML Element der Oberfläche
  • Für jeden View gibt es im Projekt eine HTML Datei, die bei Aktivieren des Views ins DOM geladen wird

Das muss erst mal reichen, weitere Details im Selbststudium…

Nun, der nächste Post der Reihe sollte sich dann auch mal wirklich um die Ziele der Evaluation kümmern – mit einem kleinen Fazit, das aber wie schon im vorherigen Post angedeutet durch unvollständige Informationen / Recherchen meinerseits verfälscht sein wird.

Jochen