Download der von mir überarbeiteten Web-Wizards:
WebWiz.zip (425 KByte)
Nach der Installation finden Sie die Web-Tools im Unterverzeichnis "Utilities\WebWizard" von Visual-dBASE 7. Die Startdatei ist das Programm "WebWizard.PRG". Nach dem Start präsentiert sich das Hauptformular mit den drei Auswahlschaltern für die drei Applikations-Typen:
Alle Assistenten setzen voraus, daß die Datenbank bereits existiert. Die Tabelle/Abfrage oder ein Datenmodul für den Dateneintrag muß vorhanden sein. Für die Abfrage muß ein (oder zwei) Berichte entworfen sein. Auch für das Report-Publishing muß logischerweise die Berichtsvorlage bereits vorhanden sein. Der Speicherort der dBASE-Daten ist dabei beliebig und darf durchaus auf einem anderen (lokalen Netz)-Laufwerk liegen als die Webseiten der Applikation.
Der Assistent für diesen Anwendungstyp führt Sie in 13 Schritten zur fertigen Web-Anwendung. Der Ordner als Speicherplatz für das HTML-Formular ist als absoluter Dateipfad des Betriebssystems aufzufassen. Er liegt im Dokumentenbereich Ihres Webs. Auch der Ordner des CGI-Verzeichnisses ist absolut gemeint. Der Dateiname gilt vordergründig für das Startformular. Aber auch die Script-EXE-Datei wird so benannt. Die Angabe zur URL ist als Alias des Webservers gemeint. Tragen Sie stets die vollständige URL einschließlich Hostname und/oder Domain ein.
In den Expertenseiten 3 bis 5 erfolgt die Auswahl der Datenbasis und der Felder für den Dateneintrag. Auf den Seiten 6 bis 10 und 12 legen Sie das Aussehen und die Texte des HTML-Formulars fest. Obwohl es möglich ist, hier einzelne Elemente exakt zu formatieren, wird dieses Vorhaben wegen des winzigen Vorschaufensters sehr erschwert. Es ist effektiver, das Formular hier nur sehr grob zu entwerfen und es später in einem üblichen HTML-Editor fein nachzuarbeiten.
Schritt 11 dient der Gestaltung der durch das Script zu generierenden Antwortseite. Auch jetzt ist das Vorschaufenster sehr winzig. Was Sie hier nicht gestalten wollen, können Sie später im Quelltext des Script-Programms ab Quelltextzeile 175 nachbessern.
Im Ergebnis der 13 Schritte werden entgegen den Behauptungen des Expertendialogs folgende Dateien generiert:
Damit ist die Anwendung funktionsfähig. Die *.PRG und *.PRO-Datei werden zur Ausführung nicht benötigt. Sie sollten sie aus dem CGI-Verzeichnis entfernen. Bewahren Sie sie aber für eine spätere Änderung der Anwendung auf.
Die HTML-Codierung des Startformulars ist korrekt und in akzeptablem Stil ausgeführt. Als Aktion des Formulars wird stets der CGI-Launcher aufgerufen und nicht Ihre dBASE-Anwendung. Belassen Sie unbedingt den generierten Mechanismus. Ein direkter Aufruf des dBASE-Scripts funktioniert definitiv nicht.
Falls Sie eine relative URL wie "/cgi-bin" für Ihr CGI-Verzeichnis vorgegeben haben, ist die Formularaktion derzeit mit "http:///cgi-bin/VdB_CGI.exe" falsch eingetragen. Löschen Sie mit einem Editor im HTML-Code des Formulars den Teil "http://" nachträglich und das Formular wird auch mit dem relativen Aktionsaufruf tadellos funktionieren. Selbstverständlich dürfen Sie weitere Veränderungen am Aussehen des Formulars vornehmen. Belassen Sie aber unbedingt die Namen der Formularfelder in der eigenwilligen Bezeichnung
"DatenbankName*@Feldname" . |
Mit der Codierung des dBASE-Programms kann man bis auf einen groben Mangel zufrieden sein, wenngleich manches effektiver erfolgen könnte. Die nicht akzeptable Einschränkung liegt bei der Behandlung der übergebenen Daten.
Die im Client eingetragenen Formularwerte werden im Script in Programmzeile 32 angeblich durch einen Funktionsaufruf nach OEM-Regeln umformatiert.
cData = OEMFormat(substr(cEnv, 1, at("&", cEnv)-1))
|
Die Funktion OEMFormat( ) beginnt ab Zeile 219 im Programmtext und verdient ihren Namen nicht. Es werden lediglich die URL-codierten Sonderzeichen Leerzeichen, Anführungs-, Plus-, Undzeichen sowie Doppelpunkt auf lesbare Normalzeichen umgesetzt. Und das relativ aufwendig! Alle anderen Escape-codierten Zeichen werden belassen.
Damit entsteht Chaos bei Verwendung der deutschen Umlaute und weiterer Sonderzeichen. Ein im Browser eingetragener Name "Müller" wird beispielsweise als "M%FCller" in die Datenbank gespeichert. Ersetzen Sie kurzerhand die gesamte Funktion OEMFormat( ) durch die Variante, die Sie auf der Erweiterungsdiskette in der Datei "OEMForm.PRG" finden. Mit dieser neuen Routine werden alle Zeichen mit Ausnahme des kaum zu erwartenden "%"-Zeichens umkodiert.
Der Kern der überarbeiteten OEM-Umkodierung benutzt folgenden Algorithmus: Es werden alle als Escape-Sequenz verschlüsselten Zeichen der Form "%99" herausgeschnitten, deren Hexadezimalwert in einen Zeichenwert umgesetzt und dieses Zeichen aus dem ANSI-Zeichensatz in den von dBASE benutzten OEM-Zeichenwert konvertiert. Das Ergebniszeichen überschreibt die dreistellige Escape-Sequenz.
do while at("%",cStr) > 0
p = at("%",cStr)
cStr = stuff(cStr,p,3,
oem(chr(htoi(substr(cStr,p+1,2)))))
enddo
|
Diese Routine sollten Sie auch in Query-und-Response-Programmen benutzen, damit der Client auch nach Begriffen mit Umlauten suchen kann. Vergessen Sie aber nicht, die EXE-Datei des Scripts neu zu compilieren.
Da die Web-Wizards selbst in dBASE geschrieben sind und der Quelltext verfügbar ist, bietet es sich natürlich an, das Problem an der Wurzel auszumerzen. Sie finden im Anhang die Datei "WizOut.CC", die die beiden in diesem Beitrag beschriebenen kardinalen Fehler des Wizards bereinigt. Die neue OEM-Formatierung wird darin ab Zeile 1823 realisiert.
Die Antwort des Scripts auf die Dateneintragung wird durch die Routine "GenerateResponse" dynamisch erstellt. Diese Antwortseite kann Grafiken und Hintergrundbilder enthalten. Der Web-Wizard kopiert diese Dateien in das CGI-Verzeichnis des Servers, damit sie die gleiche relative URL haben wie die Antwortseite und keine Pfadangaben notwendig sind. Auf vielen Webservern ist aber das Lesen von Dokumenten im CGI-Verzeichnis aus Sicherheitsgründen verboten, sodaß diese Grafiken nicht erscheinen. Die Textantwort wird aber gesendet. Legen Sie die Grafiken in ein anderes Serververzeichnis mit Leserechten und überarbeiten Sie im Quelltext der Routine "GenerateResponse" des CGI-Programms ab Zeile 175 eventuelle Grafikverweise. Nach Neuübersetzung der EXE-Datei sollte die Anwort nun bunt bebildert sein.
Eine Abfrage-und-Antwort-Anwendung wird durch den zweiten Experten in 11 ähnlichen Schritten erstellt. Zuerst wird im Schritt 4 des Assistenten die Berichtsvorlage für die Ausgabe angefordert und dann in den Schritten 5 bis 10 das HTML-Startformular entworfen.
Der Assistent bietet im Schritt 3 zwei Typen von Abfragen an:
Die einstufige Variante besteht aus dem Frageformular und der vom Script zur Laufzeit generierten Reportausgabe. Bei der zweistufigen Abfrage wird folgendermaßen vorgegangen:
Es gibt auch hier nur ein einziges HTML-Frageformular. Als erste Anwort erhält man alle passenden Daten in der durch den Report vorgeschriebenen Form. Allerdings enthalten die Ausgaben des ersten Reports in jedem Datensatz automatisch einen Link, der das zweite dBASE-Script startet. Diesem wird der jeweils angeklickte Datensatz als Parameter übergeben. Seine Ausgabe wird durch einen zweiten Report formatiert. Wenn der erste Report nur wesentliche Angaben in Listenform darstellt, der zweite Report aber auch Detaildaten in Maskenform, wird dieses Konzept zu einer sinnvollen Abfragevariante.
Auf meinem Webserver können Sie dieses Vorgehen an einem Demoprojekt (zeitlich beschränkt) live erleben. Auf Ihre Anfrage werden in einem dBASE-Telefonverzeichnis durch das erste Script die passenden Teilnehmer mit Name, Vorname und Telefonnummer ermittelt und aufgelistet. Jeder Name der Antwortliste beinhaltet einen Hyperlink auf das zweite Script-Programm, das seinerseits weitere Angaben über diesen speziellen Teilnehmer mittels eines zweiten Reports ausgibt.
Mit dem "Query-and-Response"-Assistenten erstellen Sie alle für die Applikation notwendigen Dateien. Als Antwort Ihrer Client-Anfrage werden Sie aber immer den kompletten ungefilterten Datenbestand Ihrer dBASE-Daten erhalten, egal wonach sie fragen. In der Dokumentation zu den Tools finden Sie kleingedruckt den Hinweis, daß die genaue Abfrage nachträglich in den Programmtext eingebaut werden muß.
Die einfachste Lösung dafür bietet sich in Zeile 47 Ihres Programms. Der Report ist geöffnet aber noch nicht ausgeführt. Setzen Sie dort das SQL-Objekt des Berichtes auf einen SQL-Ausdruck Ihrer Wahl. Für mein Demoprojekt "Telefonverzeichnis" lautet die einzufügende Zeile beispielsweise:
r.sql1.SQL = 'SELECT * FROM "D:\Data\TelefDat.dbf" WHERE NAME = "' + cSearch + '"' |
Den genauen Objektnamen der SQL-Abfrage innerhalb des Reports erfahren Sie über den Objektinspektor beim Berichtsentwurf. Die Variable "cSearch" beinhaltet den OEM-umkodierten Abfragestring aus dem HTML-Formular.
Auf die statischen Reports soll hier nicht eingegangen werden. Für sie gilt das im Abschnitt "Datenexport in statische HTML-Seiten" Gesagte. Die Anwendung für die dynamische Reporterzeugung besteht nur aus dem CGI-Script. Ein HTML-Startformular gibt es nicht. Um den dynamischen Report abzurufen, müssen Sie in die Adreßzeile des Browsers die URL "http://HostName/cgi-bin/VdB_CGI.exe?ScriptName.exe" eintippen oder einen derartigen Hyperlink in eine andere HTML-Seite einarbeiten. Dadurch wird über den CGI-Launcher das dBASE-Programm zur Ausgabe des Reports gestartet.
Das Expertenprogramm führt Sie auf 3 Assistentenseiten zur fertigen Anwendung. Allerdings ist die erzeugte EXE-Datei wegen eines winzigen Programmierfehlers nicht lauffähig. Der Autor der Web-Tools hat vergessen, in die Zeile 10 des CGI-Programms die wichtige Anweisung
Param fOutFile |
generieren zu lassen. Damit kann das Script die Reportausgaben nicht in eine Ergebnisdatei schreiben und bleibt zur Laufzeit mit einer Fehlermeldungsbox hängen, was in dieser Form für den Server äußerst kritisch sein kann.
Entweder fügen Sie per Hand in jedes generierte Programm für dynamische Reports in Zeile 10 den vergessenen Befehl ein und übersetzen das EXE-Programm neu oder Sie benutzen künftig den korrigierten Web-Wizard "WizOut.CC" von der Diskette. Hier wurde in Zeile 1730 die Ursache dieses Fehlers korrigiert.
Bis auf diesen kleinen aber entscheidenden Fehler ist auch der Anwendungstyp "Live Report" brauchbar. Allerdings wird in Anwendungen dieses Typs vom Web-Wizard die Funktion "OEMFormat( )" zum Umkodieren von Eingaben hineingeneriert, was aber völlig nutzlos ist.
Die Web-Wizards sind tatsächlich geeignet, um in weniger als 10 Minuten eine komplette Web-Applikation zu erstellen und diese auf dem Server betriebsbereit zu machen. Durch die Benutzerführung mittels Experten sind dazu im Idealfall nicht einmal Progrmmierkenntnisse notwendig. Das ist eine hoch zu bewertende Leistung. Allerdings kommen hierfür nur Anwendungen mit ganz bescheidenen Ansprüchen in Hinblick auf Gestaltung und Funktion in Frage.
derzeitige Mängel
In der gegenwärtig vertriebenen Version der Web-Tools stecken noch eine Reihe von Fehlern, die nur mit einiger Erfahrung im Bereich des Webdesigns manuell in angemessener Zeit ausgeglichen werden können.
Das realisierte Gesamtkonzept zählt nicht zu den fortschrittlichen Webtechnologien sondern ist eine Variante, das sonst ganz und gar nicht webfähige Visual-dBASE ins TCP/IP-Netz zu bringen.
Auf der Diskette zur Erweiterungsausgabe finden Sie einen überarbeiteten Web-Wizard "WizOut.CC" mit folgenden Besonderheiten:
Alle Veränderungen gegenüber dem Original sind mit "&&" kommentiert. Die Zeilennummern wurden beibehalten.
Download der von mir überarbeiteten Web-Wizards:
WebWiz.zip (425 KByte)
© J. Hummel, Juli 1998
[ Seitenanfang ] [ Web-Tools ] [ Startseite ]