Changes between Version 3 and Version 4 of skripte-als-webservice

Timestamp:

Aug 8, 2011, 12:57:19 PM (14 years ago)

Author:

Wolfgang Schmidle

Comment:

--

skripte-als-webservice

@@ -38 +38 @@
 Die Reihenfolge der Parameter ist egal. Man kann also auch nicht --dir angeben, dann ein paar Dateien, dann ein neues --dir und weitere Dateien. Innerhalb eines Parameters wie wordlist ist die Reihenfolge der Dateien wichtig.
 
---dir besser mit / am Ende? Bisher: wenn es $dir gibt, hänge $dir/ vorne an den Dateinamen dran. Mit / könnte ich $dir einfach auf Verdacht ohne Änderungen dranhängen. Oder: Wenn $dir ungleich "" ist, aber nicht mit / endet, hänge / dran? Was ist üblich?
+Parameter --dir besser mit / am Ende? Bisher: wenn es $dir gibt, hänge $dir/ vorne an den Dateinamen dran. Mit / könnte ich $dir einfach auf Verdacht ohne Änderungen dranhängen. Oder: Wenn $dir ungleich "" ist, aber nicht mit / endet, hänge / dran? Was ist üblich?
 
 Input und output sind immer UTF-8. Der input wird im Skript wie bisher mit "while(<>)" ausgelesen. Das funktioniert mit STDIN und Dateinamen. Ich verwende jetzt doch nicht "input=", weil alles, was nicht eine Option ist, als Dateiname interpretiert wird. (Mehr als ein Dateiname ist eigentlich bei keinem Skript sinnvoll, aber es ist nicht verboten). Ich verwende auch kein "output=", weil die defaults STDOUT für Text und STDERR für Fehlermeldungen eigentlich gut genug sind. Falls nötig, kann ich in die Fehlermeldungen auch noch Fehler-Codes hineinschreiben.
@@ -56 +56 @@
 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. (Man sollte mal eine Liste machen, wohin die Teile im Repository kopiert werden müssen.) Die Dateien "reg-wordlist-lat-alvarus.txt" etc. würde man dann wohl nicht mehr in trunk/texts/aux, sondern in Filter_parameters haben.
+aus dem Repository in das Textfilter-Verzeichnis kopiert hat. (Man sollte mal eine Liste machen, wohin die Teile im Repository kopiert werden müssen.) 
+
+Die Dateien "reg-wordlist-lat-alvarus.txt" etc. würde man dann wohl nicht mehr in trunk/texts/aux, sondern in Filter_parameters haben.
 
 == 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.?
+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`. 
 
 == Commandline versus Textfilter