Changes between Version 11 and Version 12 of skripte-als-webservice

Timestamp:

Aug 8, 2011, 2:36:11 PM (13 years ago)

Author:

Wolfgang Schmidle

Comment:

--

skripte-als-webservice

@@ -4 +4 @@
 
 Ziel: Die [wiki:workflow Skripte] sollen als funktionieren als
-* Textfilter
+* [wiki:workflow#Textfilter Textfilter]
 * auf der Commandline: mindestens einzeln, möglichst auch in einer Unix-pipe
 * mit einem in Java geschriebenen Wrapper als Webservice
@@ -25 +25 @@
 == Getopt
 
-Ich verwende jetzt das Perl-Modul Getopt::Long (und Pod::Usage). Dadurch ergibt sich recht natürlich folgendes Format, das auch für Textfilter funktioniert:
+Ich verwende jetzt das Perl-Modul [http://perldoc.perl.org/Getopt/Long.html Getopt::Long] (und [http://perldoc.perl.org/Pod/Usage.html Pod::Usage]). Dadurch ergibt sich recht natürlich folgendes Format, das auch für Textfilter funktioniert:
 
  perl script.pl [options] [file.xml]
@@ -74 +74 @@
 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.
+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
@@ -80 +80 @@
 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.
+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`.