Changes between Version 25 and Version 26 of skripte-als-webservice

Timestamp:

Aug 11, 2011, 2:57:44 PM (13 years ago)

Author:

Wolfgang Schmidle

Comment:

--

skripte-als-webservice

@@ -130 +130 @@
 3. falls das Skript als Textfilter läuft, eine zusätzliche Datei in Filter_parameters/$name.txt. Schritt 3 ist nötig, weil man einem Textfilter keine Parameter übergeben kann. Beispiel: `Text Filters/Filter_5_01_insert_reg.pl` sucht in `Text Filters/Filter_parameters/Filter_5_01_insert_reg.txt`.
 
-Ich verwende jetzt, im Gegensatz zu vorher, einen relativen Pfad, weil es sonst nicht ohne Änderungen funktioniert, nachdem man das Verzeichnis
-[source:trunk/schema/scripts/workflow]
-aus dem Repository in das Textfilter-Verzeichnis kopiert hat. Siehe [wiki:workflow_tutorial], insbesondere den [wiki:workflow_tutorial#Variante3:ArbeitmitTextwranglerBBEditaufAppleMacOS  Abschnitt für BBEdit].
+Ich verwende hier einen relativen Pfad, weil das Skript das Verzeichnis `trunk/texts/aux` sonst gar nicht finden würde. Siehe auch [wiki:workflow_tutorial], insbesondere den [wiki:workflow_tutorial#Variante3:ArbeitmitTextwranglerBBEditaufAppleMacOS  Abschnitt für BBEdit]. Im Unterverzeichnis `Filter_parameters` sind nur Dateien, in denen die Parameter so stehen, wie man sie auch in die Commandline schreiben würde. Die Dateien `reg-wordlist-lat-alvarus.txt` etc., auf die sich die Parameter-Werte beziehen könne, sind weiterhin in `trunk/texts/aux`.
 
-Die Dateien `reg-wordlist-lat-alvarus.txt` etc. würde man dann wohl nicht mehr in `trunk/texts/aux`, sondern in `Filter_parameters` haben.
+Für den Webservice ist Schritt 3 nicht relevant.
 
 === Unterschiedliche Parameter-Formate
 
-Der Parameter "wordlist" heißt "reg.wordlist" in <parameters>, etc. Wenn man das nicht will, muss man auf namespaces verzichten und hoffen, dass die Skript-Parameter-Namen sich nicht beißen. Und es gibt (wenige) Parameter, die zu mehr als einem Skript gehören. Unterelemente von <parameters> finde ich übertrieben. Oder <parameters skript="Filter_insert-reg">, etc.? Dann kann man die namespaces weglassen.
+Zu Schritt 2: Der Parameter "wordlist" heißt "reg.wordlist" in <parameters>, etc. Wenn man das nicht will, muss man auf namespaces verzichten und hoffen, dass die Skript-Parameter-Namen sich nicht beißen. Und es gibt (wenige) Parameter, die zu mehr als einem Skript gehören. Unterelemente von <parameters> finde ich übertrieben. Oder <parameters skript="Filter_insert-reg">, etc.? Dann kann man die namespaces weglassen.
 
 Und alle Parameter in einem <parameters> ohne @skript würden sich auf alle Skripte beziehen. Außerdem könnte man den Inhalt von <parameters> ebenfalls mit Getopt::Long einlesen, um ein einheitliches Parameter-Format zu haben. Ein einzelnes Skript würde dann den Inhalt von <parameters> und <parameters script="name"> übergeben. Oder vielleicht doch kein <parameters> ohne @script, denn in `Filter_parameters` gibt es auch keine Datei, die für alle Skripte gilt. Dann muss man allgemeine Parameter eben für alle relevanten Skripte wiederholen. Kein großer Aufwand.
 
 Vorschlag also: <parameters> kann mehrfach verwendet werden, mit obligatorischem @script. Darin das gleiche Optionen-Format wie auf der Commandline, einlesen mit `GetOptionsFromString`. 
+
+Meeting 2011-08-11: Wir einigen uns darauf, dass diese Art, die Parameter zu übergeben, nicht so wichtig ist. Da es bereits eine Implementierung gibt, lohnt es sich erstmal nicht, hier weiteren Aufwand zu treiben. Es sollte nur dokumentiert sein. (Parameter in den Metadaten ganz weglassen? Dann: Commandline liest ihre Parameter, Textfilter liest seine Parameter-Datei, sonst nichts.)
+
+Meeting 2011-08-09: Abhängigkeiten der Skripte genauer dokumentieren! Bisher geht der Workflow davon aus, dass alle Skripte aus dem Workflow-Schritt 1 durchgelaufen sind, bevor man zu Schritt 2 geht, etc. Das kann beim Webservice anders sein. Idealerweise merkt ein Skript von allein, wenn das Input-File nicht die richtige Form hat. Ein Skript kann auch zum Beispiel intern erst ein Prüfskript wie [wiki:workflow#a2.07prüfetags 2.07 Prüfe tags] aufrufen, oder der Webservice weiß, dass dieses Skript vorher verwendet werden muss.
 
 === Commandline versus Textfilter
@@ -154 +156 @@
 Alternative wäre, zum Beispiel zu prüfen, ob in Schritt 1 und 2 irgendwelche Optionen gesetzt wurden. Dann würden beim Aufruf auf der Commandline ohne jeden Parameter wie bei der Verwendung als Textfilter die Standard-Parameter aus der zusätzlichen Datei verwendet werden, aber sobald man irgendeinen Parameter setzt, wird die zusätzliche Datei nicht mehr eingelesen. Welche Variante führt zu möglichst wenig Verwirrung?
 
+Meeting 2011-08-11: Erstmal bei BB_DOC_NAME bleiben. Die Parameter aus Schritt 3 werden also nur dann eingelesen, wenn das Skript als (BBEdit-)Textfilter läuft. Wenn ein Skript auf der Commandline ohne Parameter aufgerufen wird, muss es entscheiden, ob es trotzdem durchläuft oder ob es USAGE ausgibt. Das reg-Skript zeigt dann zum Beispiel USAGE.
+
 Nachbilden der Möglichkeit, den Textfilter mit einem Ausschnitt einer Datei aufzurufen: Optionen wie "startzeile" und "endzeile" oder gar die genauen Spalten haben wir ja erstmal verschoben. Vielleicht könnte man das auch sowieso besser im Webservice-Wrapper machen. Dann muss es nicht in jedem Skript einzeln stehen. (BBEDIT übergibt übrigens runtime environment variables für Startzeile und -spalte etc. an den Textfilter. Diese Information wird jedoch zurzeit nicht verwendet.)