MathCoach

Der MathCoach-Web Server umfasst diese Funktionen:

  • Stellt das Web-Service MathCoach mit dem MathCoach Transport Protokoll zur Verfügung, damit die Studenten die in LaplaceScript implementierten Aufgaben üben können. Das Web-Service mathcoach bietet weder Authentifizierung noch Autorisierung an.

  • Stellt das Web-Service Uploader zur Verfügung, damit die Autoren der LaplaceScript ihren Skripten und die zugehörigen Ressourcen wie Bilder, Flash, etc. über das Web-Browser hochladen kann. Uploader bietet die Authentifizierung (Der Autor der LS muss sich anmelden) und Autorisierung an (Der Autor kann nur seine eigenen LS hochladen, editieren, entfernen).

  • Bietet das LTI-Schnittstelle an, damit der Autor der LaplaceScript eine Möglichkeit hat, die Lern-Zustand und die erreichenden Punkten der Studenten an LMS zu ermitteln, falls MathCoach innerhalb eines LMSs läuft.

So haben wir eine Definition von MathCoach-Web Server. Alles, was nicht zur den oben genannten Funktionen gehört, soll nicht in dem MathCoach Web Server implementieren. Halten wir an diese Regel, haben wir ein sauberes, wartbares Web-Server, der robust läuft. :)

Installation von MathCoach

Die Idee hinter dem Nutzung von dem Build System Maven und Source Code Manager Git ist, die MathCoach-Versionen in verschiedenen Kontext automatisch zu synchronisieren. Damit können wir

  • die produktive Version auf mathcoach.htw-saarland.de:8080 mit der Autor-Version der MathCoach auf newton.htw-saarland.de:8080 automatisch synchronisieren,

  • zur jeder Zeit die Version des MathCoach-Server auf dem mathcoach.htw-saarland.de nachvollziehen,

  • die Bugfix automatisch von newton.htw-saarland.de:8082 an mathcoach.htw-saarland.de:8080 ohne den Server neu einzustellen übertragen.

Mit diese Feature können wir die Deployment — Hotfix — Deployment -Prozess effektiver und weniger fehleranfällig ausführen.

Der Hinweis-Box am Anfang jedes Abschnitts erklärt die minimalsten Wissen und verweist i.d.R auf ein ready-to-use Datei. Verfolgt man diese Hinweis Box, kann man schnell ein lauffähiges MathCoach-Server, ohne tiefe Einarbeitung in der Architekt und Struktur des Systems, aufsetzen. Vorausgesetzt ist natürlich ein gewiesene Kenntnisse in der Stoff.

Installation auf einem produktiven System

Der MathCoach Server wird mit dem Betriebsystem Benutzer mathcoach betrieben. Der Benutzer mathcoach besitzt ein Tomcat Server, welche auf dem Port 8080 lauft.

Die einmalige Einstellungen

Voraussetzungen des Systemes für das Deployment sind:

  • Java JDK 1.8,

  • Tomcat 8.5.x,

  • Maven 3.0.x,

  • Git 1.9 / 2.0 und

  • Lesen Zugang zum ssh://newton.htw-saarland.de:/var/gitrepos/mathcoach.git

Tomcat

Version von Tomcat: 8.5.5

Note
 Ein Beispiel der Datei tomcat-users.xml kann man im Anhang tomcat-users-xml-code finden. Man kann via copy & paste die Konfiguration in einem laufenden Tomcat übertragen.

Wir gehen davon aus, dass Tomcat in ~/tomcat-servers installiert wird. Der Benutzer mathcoach muss einen Schreib-Recht in diesem Ordner haben.

Wir installieren Tomcat mit folgenden Befehlen:

cd ~/tomcat-servers/
wget https://archive.apache.org/dist/tomcat/tomcat-8/v8.5.5/bin/apache-tomcat-8.5.5.tar.gz
# wget http://apache.mirror.digionline.de/tomcat/tomcat-7/v8.0.20/bin/apache-tomcat-8.0.20.tar.gz
tar xvfz apache-tomcat-*.tar.gz

Der Tomcat Server ist dann installiert. Die Notation $TOMCAT_HOME bezeichnet den Ordner ~/tomcat-servers/apache-tomcat-8.0.20.

Wir richten eine Kennung für Tomcat-Administration ein, indem wir die Element tomcat-users in der Datei $TOMCAT_HOME/conf/tomcat-users.xml mit

<role rolename="manager-script" /> <!--<1>-->
<role rolename="manager-gui" /> <!--<2>-->
<user username="mathcoach" roles="manager-script,manager-gui" password="mathcoach" />

erweitern.

Mit der Erweiterung definieren wir 2 neue Rollen und die Kennung mathcoach, die diese 2 Rollen spielt. Diese Kennung wird in der Datei settings.xml auch eingerichtet (Authentifizierung gegenüber dem Server<maven-authentifizierung>). Mit der Kennung mathcoach kann man folgendes machen:

  1. Die Rolle manager-script erlaubt es, ein Web Application via http zum Deployment.

  2. Die Rolle manager-gui erlaubt es, ein Web Application mit Hilfe von dem Manager Application (/manager/html) zum Deployment. Mehr Informationen über den Manager Application kann man in http://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html finden.

Ab Tomcat 8.5.x muss man die Cache Speicher erweitert: Man fügt folgenden Zeile im Tag Context der Datei ${TOMCAT_HOMe}/conf/context.xml

<Resources
                cachingAllowed="true"
            cacheMaxSize="100000"
/>

Nun starten wir den Tomcat:

cd $TOMCAT_HOME/bin
./start.sh

Tomcat ist jezt bereit zum Deployment der MathCoach-Web-Application in der Form einer WAR-Datei.

Note
 Tomcat benutzt die Umgebungsvariablen JRE_HOME und JAVA_HOME um den Installationsordner der Java JRE bzw JDK zu determinieren. Falls man diese Variable in $HOME/.profile definiert und den Benutzer via den Befehl su anmelden, muss man den Befehl source absetzen: 
su mathcoach                # man meldet aus root sich als mathcoach an
source ~/.profile           # jezt ist der aktive Benutzer mathcoach, man muss .profile "sourcen"
Maven

Maven wird als Build-System verwendet.

Install von Maven

Wir installieren Maven mit folgenden Befehlen. Der Benutzer ist mathcoach.

mkdir -p ~/opt
wget http://apache.mirror.iphh.net/maven/maven-3/3.2.3/binaries/apache-maven-3.2.3-bin.tar.gz
tar xvfz apache-maven-3.2.3-bin.tar.gz -C ~/opt
mkdir -p ~/bin (4)
ln -s ~/opt/apache-maven-3.2.3/bin/mvn ~/bin/mvn (5)
source ~/.profile (6)

Die Zeile 4, 5, 6 erzeugen einen Symbolic Link vom Befehl mvn in der Ordner $HOME/bin/ und export diesen Ordner in $PATH.

Note
 Diese Befehlen setzen das System voraus, dass es in der der Datei $HOME/.profile folgenden Zeilen gibt, falls es nicht gibt, kann man ergänzen. 
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Alternative können wir die mitgeliferte Maven in MathCoach Ordner nutzen.

Einstellung von Maven

Note
 Die vollständige Auszug der ~/settings.xml wird in setting-xml-code ausgedrückt. Hier sind die Erklärung der einzelnen Einstellung-Elementen.

Die Einstellung von Maven dient zu einigen Zweck:

  1. Die Information zur Authentifizierung gegenüber dem Deployment Server nicht in pom.xml gespeichert, sondern in local, für jede Entwickler. Hier gibt es zwar keinen Entwickler, dennoch fungiert der Benutzer mathcoach als ein Entwickler, der nur die MathCoach im produktiven Server das Deployment macht.

  2. Maven benutzt den eigenen Repository in newton als central.

  3. Feststellung der Deployment URL.

Diese Einstellungen muss man in der Datei $HOME/.m2/settings.xml festlegen. Der Inhalt dieser Datei wird in dem folgenden Auszug:

  1. Die Informationen zur Authentifizierung gegenüber dem Deployment Server: Der Tag servers definiert eine Reihe von Server ID und die Informationen für die Authentifizierung gegenüber den Servern, Information jeweiliger Servern werden in dem Tag server gekapselt. Der Inhalt der Tag id in dem pom.xml der MathCoach Projekt muss zu den Inhalt der selbigen Tag in der Datei settings.xml passen.

  2. Der Repository central neu definieren: Der Tag repository definiert verschiedenen Repositories. Mehrere Repositories werden in dem Tag repositories zusammengefasst. Maven wird die Bibliotheken aus http://repo1.maven.org/maven2/ herunterziehen, wenn es keinen servers-Tag und keine repositories-Tag gibt. Diese Server bezeichnet Maven als central-Repository.

Wir müssen den central Repository überschreiben, somit der Maven nur Bibliotheken aus unsere Repository herunterziehen deshalb hat der Tag id den Wert central.

Das gleich gilt auch für Bibliotheken, die noch in SNAPSHOT-Zustand.

Neben den Bibliotheken braucht Maven auch Plugin um den Build-Vorgang auszuführen. Maven wird auch diese Bibliotheken aus dem central-Repository herunterziehen. Deshalb müssen wir die Repositories für Plugin auch definieren:

  1. Feststellung der Deployment URL: Wir definieren die Deployment URL durch das Property deploy.url. Diese Property kann man in pom.xml mit dem Ausdruck ${deploy.url} zugreifen. Damit kann jeder Entwickler MathCoach in unterschiedlichen Servers Deploy machen, ohne die gemeinsame Datei pom.xml zu ändern.

Git produktive Reposoties

Um MathCoach zu betreiben brauchen wir 2 Git-Repositories zu klonen. Zum einen ist die Repository für MathCoach Web App, zum anderen ist die Repository für die Lapalce Script und WWW Dateien der Autoren. Wir setzen voraus, dass Git ordentlich im System installiert ist, und der Benutzer den SSH Lese-Zugriff auf newton.htwsaar.de.

Clonen der MathCoach Web Application

Wir klonen MathCoach Web Application im Ordner $HOME/deploy-mathcoach.

deploy-mathcoach kann durch anderen Name ersetzen, nur nicht den Name mathcoach.

Clonen der LaplaceScript Repository

Danach klonen wir die Repository der LaplaceScript in $HOME:

code,sourceCode,bash
cd $HOME
git clone ssh://${gitblit-user}@newton.htwsaar.de:/virtual-file-system.git
cd virtual-file-system
git checkout mathcoach

Deployment der MathCoach Web-App

Wir müssen folgende Schritten machen wenn wir einen neuen Deployment der MathCoach Web-App aufführen:

cd ${HOME}/deploy-mathcoach/mathcoach
git checkout master
git pull
./one-click-deploy.sh

Installation auf einer Entwicklungsumgebung

In eine Entwicklungsumgebung braucht man nur MathCoach Web-App zu klonen und das MathCoach konfigurieren. Die Routinen Code — Compile — [Test] — Deploy macht die Entwicklungsumgebung selbst.

Einrichten der Datenbank

Tabellen für die LTI-Schnittstelle

Damit die LTI-Schnittstelle funktioniert, müssen die notwendigen Datenbanktabellen angelegt werden. Das Datebankschma sowie die notwendigen Datenbank-Funktionen befinden sich in der Datei laplace-parser-lti/src/main/postgresql/lti_schema.sql. In der PSQL-Konsole kann das Skript mit dem Befehl \i lti_schema.sql ausgeführt werden.

Konfiguration von MathCoach

MathCoach braucht an 3 Stelle zu konfigurieren:

  • $TOMCAT_HOME/conf/tomcat-user.xml Konfiguration für die Authentifizierung von Autoren und Admin,

  • $HOME/mathcoach/laplus-config.xml Konfiguration für den Betrieb des MathCoach Web App,

  • $HOME/mathcoach/logconfig.xml Optionale Konfiguration für den Log der MathCoach Web App.

Authentifizierung & Autorisierung

Unter Authentifizierung versteht man die Überprüfung, ob jemand das System zugreifen darf. Unter Autorisierung versteht man die Überprüfung, ob jemand berechtigt, eine Operation auf dem System auszuführen.

Die Authentifizierung in MathCoach wird mit Hilf von Kennung-Passwort implementiert. Die Autorisierung wird mit Hilf von Rolle-Zuweisung implementiert. Die Implementierung von beide basiert auf UserDatabaseRealm .

Die Kennungen und Passwörter so wie die Rolle der Benutzer werden in der Datei ${CATALINA_BASE}/conf/tomcat-users.xml

eingetragen. Der Syntax der Datei sieht so aus:

<tomcat-users>
   <role rolename="${roll1}" />
   <role rolename="${roll2}" />
   <!-- other roles -->

   <user name="${kennung}" password="${password}" roles="${rolle1},${roll2}" />
   <!-- other users  -->
</tomcat-users>

  • Der Tag code definiert, welche Rolle gibt es in Tomcat. Die Anzahl der Rolle ist beliebig erweiterbar.

  • Der Tag user definiert die Benutzer in Tomcat. Durch das Attribute roles kann man die Rolle an dem Nutzer zuweisen.

MathCoach braucht 2 Rollen um ordentlich zu laufen:

ls-author

Damit ein Laplace Script Autor die Virtual File System zugreifen kann, muss er als erste Bedingung ls-author zugewiesen werden. Zweitens muss sein VFS und WWW-Ordner vorhanden sein (mehr dazu später).

ls-admin

Um die Betriebskonfiguration einzustellen, sprich die Seite ${mathcoach}/config/index.jsp im Browser aufzurufen, muss der Benutzer sich als ls-admin anmelden.

Eine vollständige Config-Datei tomcat-users.xml für MathCoach sieht so aus:

<tomcat-users>
    <!-- mathcoach' Laplace Script Authors and Admins -->
    <role rolename="ls-author" />
    <role rolename="mc-admin" />

    <user username="demo" password="demo's-password" roles="ls-author" />
    <user username="brueckenkurs" password="bk-pass" roles="ls-author" />

    <user username="mcadmin" password="der-admin" roles="mc-admin" />
    <user username="gott" password="super-kraft" roles="ls-author,mc-admin" />
</tomcat-users>

Betriebskonfiguration

Die Betriebskonfiguration wird in der Datei ${HOME}/mathcoach/laplus-config.xml gespeichert. Wobei ${HOME} ist das Home-Verzeichnis der Betriebssystem’s Benutzer unter welche das MathCoach läuft.

Diese Datei wird automatisch generiert, wenn die Seite ${mathcoach}/config/index.jsp aufgerufen wird und die Konfigurationsformular erfolgreich am Server gesendet wird. Die Einträge deren Beschreibungen wird automatisch zusammengefasst. Die Autor der Plugin muss dafür sorgen, dass seine Plugin richtige Konfigurationsparameter und dessen Beschreibung deklariert.

Die wichtigsten Konfigurationen sind:

  • application-path: /var/tomcat-servers/apache-tomcat-7.0.56/webapps/mathcoach Der absolute Path zum MathCoach Web-App, i.d.R ist der Odner in Tomcat’s webapp, wo die MathCoach liegt.

  • author-root: /home/mathcoach/virtual-file-system/vfs Der Odner, wo die Virtual File System liegt, er enthält als Kinder-Odner die Home-Odner der Autoren.

  • author-www: /home/mathcoach/virtual-file-system/www Der Ordner, wo die WWW-Verzeichnisse der Autoren liegen.

  • author-www-tmp: author_tmp Der Ordner, wo die ein LaplaceScript seine temporären Dateien in einer Session speichern kann, somit der Benutzer diese Dateien via http zugreifen kann. Dies Konfiguration Parameter wird als relative Pfad zu application-path interpretiert.

  • class-path: /var/tomcat-servers/apache-tomcat-7.0.56/webapps/mathcoach/WEB-INF/classes Der Ordner von Tomcat, wo die Class Dateien angelegt wird. Der Ordner ist ein Teil der Classpath. In der Regel ist er der absolute Pfad der Ordner WEB-INF/classes.

Man kann die andere Konfiguration-Parameter mit ${config-name} referenzieren, etwa

<param-1>xxx</param-1>
<param-2>${param-1}/yyyy</param2>

Die rekursive Referenz werden automatisch ausgelöst. Taucht zyklische Referenz auf, wird ein Fehlermeldung ausgegeben.

Der Link http://localhost:8080/mathcoach/config/index.jsp gibt uns eine Überblick von alle Konfigurationsparameter in MathCoach.

Log Konfiguration

Den Details über die Log Konfiguration kann man im Kommentar der Datei ${HOME}/mathcoach/logconfig.xml entgegennehmen. Weitere Informationen sind auf der Homepage von Logback verfügbar.

Cargo Konfiguration für Integration Test

Das Maven Plugin cargo-maven2-plugin wird in dem Integration Test Phase genutzt, um ein in Rechner installierten Tomcat Instanz zu starten und zu stoppen. Die Konfiguration vom Plugin ist umständlich, von daher wird die Konfiguration so weit wie möglich an Standard gehalten.

Der Exercise-Link dient zum Verteilen der MathCoach Aufgaben, sowie als Endpunkt für die LTI-Schnittstelle.

Der Exercise-Link ist nach folgendem Muster aufgebaut:

{http|https}://{host}[:{port}]mathcoach/Exercises?path=demo/funktionstests&script=helloworld

Ein GET-Request zieht das Laden einer MathCoach Aufgabe nach sich, ein POST-Request ist für den LTI-Launch vorgesehen. Auf diese Weise kann der selbe Link zum direkten Zugriff auf die MathCoach Aufgabe, sowie zum Zugriff über einen LTI-Tool-Consumer (z.B. OpenOlat) verwendet werden.

Der Parameter path gibt das Verzeichnis, in dem sich das LaplaceScript befindet an. script bezeichnet den Namen des LaplaceScriptes.

Die Parameter path und script ersetzen die alten Parameter author und load, siehe MCTransportProtokoll.

Laden einer LaplaceScript Aufgabe

Ein GET-Request dient zum Laden einer LaplaceScript Aufgabe. Für den Endnutzer verhält sich der Exercise-Link wie der alte Link zum Verteilen der MathCoach Aufgaben. Auf technischer Seite wird die Anfrage jedoch anders verarbeitet, sodass beispielsweise ein LaplaceScript-Autor über das Layout bestimmen kann.

Endpunkt für die LTI-Schnittstelle

LTI-Tool-Consumer (z.B. OpenOlat) können den selben Exercise-Link für einen LTI-Launch verwenden. Dabei wird ein POST-Request verwendet. Nachdem die zusätzlichen LTI-spezifischen Parameter erfolgreich ausgewertet wurden, findet eine browserseitige Weiterleitung zum Laden einer LaplaceScript Aufgabe statt. Da das LaplaceScript nun in einer LTI-Umgebung ausgeführt wird, hat der Script-Autor die Möglichkeit Noten an den LTI-Tool-Consumer zu übertragen.

Details zur Implementierung

Übersicht der einzelnen Komponenten

Laden einer LaplaceScript Aufgabe

Durch Senden eines GET-Request an das Exercise-Servlet wird eine LaplaceSession erzeugt und das geforderte Script gestartet. Das vom Autor gewünschte Layout kann aufgelöst werden. Zugriffe auf das LaplaceServlet können via JavaScript erfolgen.

Um dem Autor die Wahl des Layouts zu ermöglichen musste die bestehende Architekur, siehe MCTransportProtokoll, überarbeitet werden.

Das LaplaceScript muss zuerst gestartet werden, sodass man Zugriff auf die Layout-Information hat. Ein Weiterleiten an die Layout-JSP (z.B. frame.jsp) erfolgt. Der Programmcode zum Starten eines Scriptes, sowie zum Erzeugen der LaplaceSession ist aus dem LaplaceServlet herausgezogen und wird fortan vom ExerciseServlet übernommen. Folgeaufrufe an das LaplaceServlet, via JavaScript, verhalten sich wie vorher.

Endpunkt für die LTI-Schnittstelle

POST-Requests werden als LTI-Launch behandelt. Nachdem die LTI-spezifischen Parameter (Signatur, ResourceId, usw.) erfolgreich ausgewertet sind, werden verschiedene Attribute der Session gesetzt. Es erfolgt eine Weiterleitung an das ExerciseServlet (diesmal ein GET-Request), sodass die Aufgabe geladen werden kann. Einziger Unterschied ist, dass die Session eine LTI-Umgebung bereitstellt, welche von entsprechenden Tags im LaplaceScript verwendet werden kann.

Weitere Informationen

  • lti-configuration

  • lti-configuration-database

  • rest-api-lti-tool-consumer

API-Endpunkte

MathCoach stellt zahlreiche JSON-basierte APIs bereit. Die Endpunkte sind ausgehend von der Base-Url https://xxx.htwsaar.de/mathcoach angegeben. Einige API-Endpunkte sind geschützt und nur für eingeloggte Benutzer mit der Rolle ls-author bzw mc-admin erreichbar.

Im Fehlerfall nutzen die API-Endpunkte einen HTTP-Fehler-Code und geben ein JSON-Objekt mit folgendem Aufbau zurück:

{
    "message":"Fehlermeldung für den Benutzer steht hier."
}

Nexplorer

Dateien auflisten

Endpunkt: GET /json/nexplorer/files/{part}/{path}?depth={depth}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Verzeichnis-Pfad

folder1, folder1/subfolder1. Keine Angabe entspricht dem Wurzelverzeichnis

depth (optional)

Wie tief soll in der Hierarchie gesucht werden

Standard-Wert ist 1 - es werden keine Elemente von Unterverzeichnissen gelistet

Request

GET /json/nexplorer/files/vfs/beispiele?depth=1

Response

Zurückgegeben wird die Liste der Dateisystem-Einträge. Das erste Element entspricht dabei dem Verzeichnis, alle weiteren Elemente sind in diesem enthalten.

[
    {                                       (1)
        "path":"/beispiele",
        "baseName":"beispiele",
        "extend":"",
        "parent":"/",                       // Leerstring = kein Übergeordnetes Verzeichnis
        "mimeType":null,
        "size":-1,
        "lastModi":"2017-11-13T19:23:25",
        "actions":[]
    },
                                            (2)
    {
        "path":"/beispiele/datei1.txt",
        "baseName":"datei1",                // Dateiname ohne Extension
        "extend":"txt",                     // File-Extension
        "parent":"/beispiele",
        "mimeType":"text/plain",
        "size":3188,                        // Dateigröße in Bytes
        "lastModi":"2017-11-13T19:23:17",
        "actions":["online-editor"]         // IDs von Aktionen für die Datei
    }, {
        "path":"/beispiele/ordner1",
        "baseName":"ordner1",
        "extend":"",
        "parent":"/beispiele",
        "mimeType":null,                    // bei Ordnern null
        "size":-1,                          // bei Ordnern -1
        "lastModi":"2017-11-13T19:23:10",
        "actions":[]
    },
    ...
]

  1. Das erste Element ist das aktuelle Verzeichnis!

  2. Alle weiteren Elemente sind Dateien des aktuelle Verzeichnises

Neuen Ordner erstellen

Endpunkt: PUT /json/nexplorer/folders/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Verzeichnis-Pfad inklusive des zu erstellenden Ordners

new_folder, folder1/new_subfolder

Request

PUT /json/nexplorer/folders/vfs/beispiele/new_folder

Response

Es wird der Dateisystem-Eintrag des neu erstellten Ordners zurück gegeben.

{
   "path":"/beispiele/ordner2",
   "baseName":"ordner2",
   "extend":"",
   "parent":"/beispiele",
   "mimeType":null,
   "size":-1,
   "lastModi":"2017-11-13T20:13:50",
   "actions":[]
}

Datei hochladen

Endpunkt: PUT /json/nexplorer/folders/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Pfad zum Zielverzeichnis

someFolder, folder1/new_subfolder, keine Angabe wenn in das Root-Verzeichnis hochgeladen werden soll

Request (via HTML-Form)

PUT /json/nexplorer/folders/vfs/beispiele/folder1
Content-Disposition: form-data; name="file"; filename="someFile.txt"
Content-Type: text/html

Response

Es wird der Dateisystem-Eintrag der hochgeladenen Datei zurückgegeben.

{
   "path":"/beispiele/someFile.txt",
   "baseName":"someFile",
   "extend":"txt",
   "parent":"/beispiele",
   "mimeType":"text/plain",
   "size":3188,
   "lastModi":"2017-11-13T21:10:57",
   "actions":[
      "online-editor"
   ]
}

Datei umbenennen bzw. verschieben

Endpunkt: POST json/nexplorer/folders/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Verzeichnis-Pfad inklusive des zu erstellenden Ordners

new_folder, folder1/new_subfolder

Request

POST /json/nexplorer/folders/vfs/beispiele/ordner1
{
    "newPath":"/beispiele/ordner1Umbenannt"
}

Response

Es wird der aktualisierte Dateisystem-Eintrag zurückgegeben

{
    "path":"/beispiele/ordner1Umbenannt",
    "baseName":"ordner1Umbenannt",
    "extend":"",
    "parent":"/beispiele",
    "mimeType":null,
    "size":-1,
    "lastModi":"2017-11-13T19:23:10",
    "actions":[]
}

Datei löschen

Endpunkt: DELETE json/nexplorer/folders/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Pfad zur Datei bzw. zum Ordner

folder1, folder1/subfolder1, someFile.html, folder1/someOtherFile.txt

Request

DELETE /json/nexplorer/files/vfs/beispiele/ordner1/someFile.txt

Response

Es werden keine Daten zurückgegeben.

Datei oder Ordner herunterladen

Dateien lassen sich einzeln herunterladen. Ordner werden als .zip-File heruntergeladen.

Endpunkt: GET json/nexplorer/downloads/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Pfad zur Datei bzw. zum Ordner

folder1, folder1/subfolder1, someFile.html, folder1/someOtherFile.txt

Request

GET /json/nexplorer/downloads/vfs/beispiele/datei1.txt
GET /json/nexplorer/downloads/vfs/beispiele/someFolder

Online-Editor

Datei einlesen

Endpunkt: GET /json/online-editor/files/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Pfad zur Datei

someFile.txt, someFolder/someFile.txt

Request

GET /json/online-editor/files/vfs/beispiele/datei1.txt

Response

Die Rückgabe enthält mit fileInfo Informationen über den Dateisystem-Eintrag (siehe Nexplorer) der Datei und mit fileContent den Datei-Inhalt als String.

{
   "fileInfo":{
      "path":"/beispiele/datei1.txt",
      "baseName":"datei1",
      "extend":"txt",
      "parent":"/beispiele",
      "mimeType":"text/plain",
      "size":3188,
      "lastModi":"2017-11-13T19:23:17",
      "actions":["online-editor"]
   },
   "fileContent":"... content here ..." // der Inhalt der Datei
}

Datei schreiben

Endpunkt: POST /json/online-editor/files/{part}/{path}

Parameter

Bedeutung

Beispiel

part

Geschützter oder Öffentlicher Teil des Dateisystems

vfs oder www

path

Pfad zur Datei

someFile.txt, someFolder/someFile.txt

Request

POST /json/online-editor/files/vfs/beispiele/datei1.txt
{
    "content":"... new content here ..." // der neue Inhalt der Datei
}

Response

Die Rückgabe enthält mit den aktualisierten Dateisystem-Eintrag (siehe Nexplorer).

{
   "path":"/beispiele/datei1.txt",
   "baseName":"datei1",
   "extend":"txt",
   "parent":"/beispiele",
   "mimeType":"text/plain",
   "size":6,
   "lastModi":"2017-11-13T20:58:05",
   "actions":["online-editor"]
}

LaplaceScript kompilieren

Endpunkt: GET /json/online-editor/compileable/{part}/{path}

Parameter

Bedeutung

Beispiel

part

LaplaceScripte müssen immer im vfs Verzeichnis liegen

vfs

path

Pfad zum LaplaceScript

aufgabe.ls, someFolder/aufgabe.ls

Request

GET /json/online-editor/files/vfs/beispiele/aufgabe.ls

Response

Die Rückgabe enthält mit den Dateisystem-Eintrag (siehe Nexplorer). Ist das LaplaceScript nicht kompilierbar, so wird ein HTTP-Fehlercode und das Standard-Fehler-Objekt zurückgegeben.

{
   "path":"/lti.ls",
   "baseName":"lti",
   "extend":"ls",
   "parent":"/",
   "mimeType":"application/xml",
   "size":401,
   "lastModi":"2017-11-13T21:03:41",
   "actions":["online-editor","ls-info"]
}