[Allegro] "include" in acon-Jobs

[Bernhard Eversberg]

Zwar kann man "include" in der acon-Jobsprache verwenden, ABER!
Ein gravierendes Problem tritt bei Webkatalogen auf, wobei die
Jobdatei auf dem Webserver liegt oder gar eingebettet ist in
ein Skript.
Der Job wird in jedem Fall als Ganzes via avanti an acon
übermittelt, und acon liegt u.U. auf einem anderen Rechner!
Dort erst wird der Job von acon (über stdin) eingelesen.
Und beim Einlesen wird "include ..." gefunden, an der Stelle
erst kann also darauf reagiert werden. Ergo muß die zu
inkludierende Datei auf dem Datenserver liegen, nicht auf
dem Webserver bzw. dessen Dókumentenpfad. Das klappt dann auch.

Beispiel: Statt den länglichen Job  kalend.job  bei jedem
Aufruf komplett an avanti zu übersenden, würde ein Einzeiler
genügen:

include kalend.job

oder auch

include jobs/kalend.job

acon sucht dann relativ zu seinem Startpfad, den es als
ProgDir nimmt.
(Nur zur Erinnerung: so etwas wie

var P "jobs/kalend.job"
include

geht nicht! Der include-Befehl kann nicht auf die iV
zugreifen, weil er schon im Moment des Einlesens des Jobs
vararbeitet wird, nicht im Moment seiner Abarbeitung.)

Leider ist es bei Windows aber so, daß acon seinen Startpfad nicht
von avanti übernimmt, sondern es ist automatisch  c:\windows\system32,
_obwohl_ avanti ihn so startet:  c:\allegro\acon ...
Und wir wissen nicht, und waren nicht klug genug, es rauszufinden, ob
man das anders einstellen könnte.

Was man nicht machen sollte, obwohl es ginge, ist natürlich, auf Seiten
des Webservers den absoluten Pfad einzutragen, also etwa

include c:/allegro/jobs/kalend.job

Wir haben deshalb in acon eingebaut, daß acon sich seinen ProgDir
zunächst aus seinem Aufruf herausholt, was es zum Glück kann, und
zwar auch nter Linux/UNIX. (In C geht das mit getcwd())
Der "include" wird dann, nach vergeblichem Versuch des direkten
öffnens der Datei, mit vorangestelltem ProgDir ausgeführt.
So klappt dann eine relative Adressierung, wie im Beispiel gezeigt.
Das ist in acon nun realisiert und getestet.

Richtig groß dürfte der Leistungsgewinn auch wieder nicht sein.
Interessanter ist, daß man damit seine Jobs auch auf dem Datenserver
halten kann. Nicht jeder hat den Web-Dokumentenserver unter Kontrolle!
Den Webkatalog-Betreibern wird nicht entgehen, daß darin einiges
Potential liegt.

"Und die Variablen?" werden Sie fragen, "wie kriegt der Job seine
Variablen? Die müssen doch vom Webserver kommen, z.B. aus
einem Formular!" Tun sie auch, dafür sorgt ajax3.php, das
universelle Skript. Es setzt die nötigen Befehle alle ein,
genau vor den include-Hefehl, und im Job stehen sie dann
zur Verfügunng, ob es sich um #u-Felder handelt, $-Variablen,
oder echte Datenfelder. ajax3.php ist schon alt, es wurde bereits
in a30 ausgenutzt:
    http://www.allegro-c.de/db/katalog/axa.htm
inzwischen aber weiter verbessert ($-Variablen!).

Im Zuge dieser Sache wurde auch die alte ProgDir-Voreinstellung
C:\ALLEGRO  (in allegro.hpp) endlich ersatzlos rausgeschmissen.
Lieber hätten wir in Redmond ereicht, daß man die erwähnte
Windows-Voreinstellung abschaffte. Aber bis die sich bewegen ...

Die Quellen liegen im SVN.

B.E.