Mal wieder was Neues – CoffeeBreak

Nach langer Zeit habe ich mich entschieden, mal wieder einen Blick in Microsofts SharePoint zu werfen – konkret in die SharePoint Foundation 2013, auch leicht angestaubt aber besser als mein letzter Ausflug mit den Windows SharePoint Services 3.0. Tatsächlich habe ich mir dabei nur einen Aspekt herausgegriffen und ich vermute einmal, dass ich daher noch eine Menge Fehlinformationen habe und Dinge vermutlich einfacher oder überhaupt gehen: also erst mal alles in diesem und den nächsten Posts (ich habe das thematisch aufgeteilt, damit die Posts nicht zu lang werden) als Information eines Laien nehmen und nicht allzu ernst nehmen – auch wenn ich mir durchaus Mühe gegeben habe, das Richtige zu tun.

Konkret wollte ich mir anschauen, wie man ein SharePoint-Hosted AddIn (formerly known as Web App) mit der aktuellen Visual Studio 2015 Version (Update 3), TypeScript, SASS et al entwickeln kann. Entstanden ist eine kleine, in diesem Zustand nicht wirklich nützliche Anwendung namens CoffeeBreak, mit der Kaffeespenden im Büro [hm, ich denke das Prinzip kennen so einige] verwaltet werden können und die auch eine Übersicht über die Zeit gibt – der Quellcode dazu ist natürlich auch öffentlich verfügbar, Verwendung und Interpretation der Vorgehensweise wie immer auf eigene Gefahr. Der wesentliche Nachteil der SharePoint-Hosted App ist es, dass mit der Deinstallation auch immer alle Daten verloren gehen, aber darum ging es mir hier auch nicht: ich denke mal, dass man fast alles aus dieser konkreten App auch direkt mit SharePoint Bordmitteln umsetzen kann!

In diesem ersten Post nur ein paar Screen-Shots, weitere Details folgen wie gesagt separat. Zuerst einmal die Startansicht – die Anwendung läuft Stand-Alone oder auch als Client Web Part in einer SharePoint Seite:
Startansicht

Das Eintragen einer neuen Spende:
Spende anlegen

Und darüber auch das Anlegen neuer Kaffeesorten – nach der Installation gibt es davon keine:
Sorte anlegen

Soweit zur Übersicht, die anderen Posts beschäftigen sich mit der Entwicklungsumgebung und den Zielen sowie einem kleinen Fazit

Jochen

Optionale Parameter in Methoden von TypeScript Schnittstellen

Wie immer: wenn man nachher darüber nachdenkt ist alles klar, aber manchmal ist man dann einen Moment lang doch überrascht. Nehmen wir einmal folgende TypeScript Schnittstelle:

interface ISample {
do(name?: string): void;
}

Die Methode do kann nun mit oder ohne Parameter aufgerufen werden:

extra(test: ISample): void {
test.do();
test.do(undefined);
test.do('ho');
}

Um in der Implementierung festzustellen ob ein Parameter übergeben wurde verwendet man im Allgemeinen einen Vergleich gegen undefined (oder alternativ void 0) – tatsächlich müsste man arguments.length zu Rate ziehen, um die ersten beiden Varianten sicher unterscheiden zu können. Das kann TypeScript einem aber auch abnehmen:

do(name: string = 'default'): void {
}

Genau dieser Vergleich auf undefined wird hier (ohne Rücksicht auf arguments.length, i.e. die beiden ersten Aufrufvarianten werden gleich behandelt) durchgeführt und der Parameter entsprechend belegt.

Alles das war mir im Einzelnen schon klar. Schön ist aber bei genauer Betrachtung, dass im Gegensatz zu Default Werten für Parametern in C# et al nicht der Aufrufer sondern die Implementierung entscheidet, was für ein Default verwendet werden soll. In meinem konkreten Anwendungsfall gibt es dann tatsächlich unterschiedliche Implementierungen der Schnittstelle mit unterschiedlichen Bedürfnissen, wo sich dieses Verhalten dann als sehr praktisch erwiesen hat.

Netter Seiteneffekt

Jochen