[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]

Session D-VID

Einsatz von VFP 6.0 in Visual InterDev 6.0

Arturo Devigus
Devigus Engineering AG


Einführung

Visual InterDev 6.0 ist viel mehr als nur die nächste Version von Visual InterDev. Mit den leistungsfähigen neuen Datenbank Features reiht es sich als erwachsenes Web Datenbank Entwicklungs Tool in die Reihe der erfolgreichen Entwicklungstools ein. Um eine Gesamtlösung unter Integration bestehender oder neuzuentwickelnder COM Komponenten unter Visual FoxPro 6.0 zu realisieren, ist es wichtig, über die Grundfunktionalitäten von Visual InterDev 6.0 Bescheid zu wissen, um zu verstehen, wo Visual FoxPro 6.0 sinnvollerweise ergänzend eingesetzt werden kann. Das Ziel ist es, das Beste aus beiden Welten, nämlich der Windows Welt (mit Visual FoxPro als Representant) sowie der Web basierten Welt (mit Visual InterDev als Representant)  verwenden zu können. Ich werde am Schluss dieses Vortrages auch noch auf Visual Basic als ActiveX Komponenten Lieferant zu sprechen kommen und die Vor- und Nachteile gegenüber Visual FoxPro aufzeigen.

Das Leistungsspektrum von Visual InterDev 6.0

Visual InterDev 6.0 bietet dem Entwickler von Web basierten Anwendungen eine Reihe von sehr nützlichen Features. Wie wir sehen werden, lässt sich trotz der vermeintlich vielen Überschneidungen mit Visual FoxPro eine optimale Integration der beiden Entwicklungsumgebungen erzielen um somit die nächste Generation von verteilten Anwendungen erstellen zu können.

Data Environment

Wie der Name bereits vermuten lässt, stellt das Data Environment, ähnlich zum Data Environment , wie wir es von Visual FoxPro her kennen, die Definition dar, welche Data Connections (bakannt aus ODBC DSN Einträgen) und welche Data Commands in der Applikation verwendet werden.

Unter Data Commands versteht man auch Queries (analog zu den Views in Visual FoxPro), Stored Procedures sowie SQL Commands.

Die Idee hinter der graphischen Visualisierung ist, dass man Übersicht über alle Connections sowie Data Commands behält und, wichtiger noch, diese mit Drag and Drop auf die Visual InterDev Webseiten ziehen kann. Visual InterDev vollzieht dann den Rest, d.h. es werden die Design Time Controls (Server seitige ActiveX Komponenten mit Benutzeroberfläche für den Entwickler, welche die Generation von HTML Seiten gemäss definierten Eigenschaften unterstützt) automatisch auf das Form gelegt.

Die gesamten Drag and Drop Möglichkeiten im Zusammenhang mit dem Data Environment ist so leistungsfähig, dass es sich lohnt diese etwas näher zu beschreiben:

 
Drag Von Nach Resultat

Database object (z.B. eine Tabelle)

Data View (Ansicht des Tabelleninhaltes)

Connection in Data Environment

Erstellt ein Command Object, welches die in der angewählten Tabelle vorhandenen Felder und Datensätze bezieht

Command Objekt oder Feld Objekt

Data Environment

Web Seite

Data-bound Control

In diesem Zusammenhang ebenfalls wichtig zu wissen ist, dass das Drag and Drop von einem Datenbank Objekt aus einer Data View (Ansicht des Tabelleninhaltes) auf eine Web Seite nicht möglich ist. Die Idee dahinter ist, dass alles zuerst in der Data Environment Umgebung zu definieren ist. Hat man sich einmal daran gewöhnt, kann man gar nicht mehr anders arbeiten.

Data-Bound Design-Time Controls

Was aus Visual FoxPro bereits lange bekannt ist, hält nun auch bei den architekturbedingt diesbezüglich komplexeren, verteilten WebAnwendungen Einzug: Die Data Bound Controls. Im Zusammenhang mit Data-Bound Controls in der Web Umgebung darf aber keinesfalls ausser Acht gelassen werden, dass die Prozesse, wie Daten von der Datenquelle (SQL Server, Fox, Jet oder andere) auf die Benutzeroberfläche gelangen, fundamental unterschiedlich sind gegenüber den aus Visual FoxPro oder anderen Windows basierten Entwicklungstools bekannten Prozessen.

Visual InterDev bietet die Möglichkeit für ältere Browser alle Logik Serverseitig ablaufen zu lassen. Dieser Modus ist auch als ASP (Active Server Page) Modus bekannt und verwendet ausschliesslich HTML Version 3.2. Ist die Audienz mit Internet Explorer4.0 und höher ausgestattet, bietet Visual InterDev an, auf HTML 4.0, auch als Dynamic HTML bekannt, zu wechseln. Wie wir sehen werden, bietet die neue Scripting Library die notwendigen Voraussetzungen um als Entwickler nicht allzuviel an der implementierten Grundlogik verändern zu müssen wenn von der Server Seitigen Logik auf die Client Seitige Logik gewechselt wird.

Scripting Object Model

Was in Visual FoxPro und anderen Windows basierten Entwicklungstools ebenfalls seit langem bestens gelöst ist, wurde nun ansatzweise auch in Visual InterDev implementiert: Die Möglichkeit der intuitiven, ereignisgesteuerten, objektbasierten Programmierung. Neu ist es in Visual InterDev relativ einfach möglich z.B. bei Command Buttons, welche sich auf einer Webseite befinden mit einer Logig zu versehen, welche aufgerufen wird, wenn der Anwender darauf Klickt. Der Code kann dank der Scripting Library nun in der eigens dafür vorhandenen Methode onClick eingetragen werden:

Ebenso einfach lassen sich auch Ereignisse, wie das Verändern eines Inhaltes einer Textbox (in etwa verglichbar mit dem Visual FoxPro LostFocus Event) abfangen und entsprechend Code für die z.B. serverseitige Abarbeitung erfassen.

Es würde den Rahmen dieses Kurzvortrages sprengen, auf weitere Feinheiten der Scripting Library einzugehen. Es ist jedoch wichtig, dass man die Leistungsfähigkeit der Visual InterDev Umgebung als Datenbank Entwicklungstool der neuesten Art, keinesfalls unterschätzt.

Einbinden von VB Script

VB Script Komponenten können Serverseitig eingesetzt werden, um quasi als Leim die zu instanziierenden Business Komponenten zusammenzuhalten und auch einfachere Validierungen vorzunehmen. Clientseitig ist ein Microsoft Internet Explorer erforderlich um VB Script Komponenten ausführen zu können. Aus diesem Grund wird clientseitig meist Java Script verwendet oder es wird je nach Anforderungsprofil ganz auf clientseitiges Scripting verzichtet.

VB Script ist eine sehr leistungsfähige Umgebung, welche es sich auch als Visual FoxPro Programmierer lohnt, näher anzusehen! Was früher die .BAT Dateien waren, sind heute die .VBS Dateien. Mit VB Script lässt sich selbst in Produkten wie Site Server Commerce Edition einfache Prozesse, wie z.B. eine MwSt Berechnung problemlos in der Scriptor Komponente der Order Processing Pipeline implementieren. Die Anwendungsgebiete von VB Script sind geradezu immens.

In meinem Beispiel zeige ich, wie man mit VB Script im onclick() eines Command Buttons den Wert einer Textbox verändern kann:

 Sub Button1_onclick()
    txtTest.value = now
 End Sub

Der Code ist simpel und dient auch lediglich zu Demonstrationszwecken. Was man aber schön erkennt, ist, dass dank der Visual InterDev Scripting Library eine Textbox auch einfach mittels txtTest angesprochen werden kann und das die Value Property den angezeigten Wert beinhaltet.

Einbinden einer VFP 6.0 ActiveX EXE Server Komponente

Die Probleme beim Instanziieren einer Server Komponente kommen in der Regel entweder von einer unklaren NT Authentisierung oder von einer fehlenden Einstellung auf dem Internet Information Server 4.0. Im Zusammenhang mit dem Instanziieren eines OLE Servers muss man sich den Ablauf, wie ein Web Request letztendlich auf dem Server zu einer Instanziierung einer ActiveX Komponente führt, vor Augen führen. Ganz entscheidend hierbei ist es, sich darüber Rechenschaft abzulegen, welcher NT User letztendlich den OLE Server startet. Wenn man das nicht tut, wird man mit langdauernden und frustrierenden Debugging Sessions bestraft.

Erstellen des VFP 6.0 Out of Process OLE Servers

Das Erstellen des VFP 6.0 Out of Process OLE Servers läuft folgendermassen ab:

Im Projekt muss mindestens eine Klasse mit dem Attribut OLEPUBLC vorhanden sein. Es ist unerheblich, ob die Klasse(n) visuell oder nicht visuell erstellt werden. Im folgenden Beispiel wird die Klasse nicht visuell erstellt:

define class cASPEXE as custom OLEPUBLIC 
procedure init 
LOCAL lnfile 
lnfile = fcreate("c:\temp\cASPEXE_Init.txt") 
   fputs(lnfile, "cASPEXE Init has been  created at " +;
    TTOC(datetime())) 
   fclose(lnfile) 
endproc 
    
procedure getTestTime 
   return ttoc(datetime()) 
endproc 
    
procedure destroy 
   LOCAL lnfile 
   lnfile = fcreate("c:\temp\cASPEXE_Destroy.txt") 
fputs(lnfile, "cASPEXE Destroy has been  called at " +;
 TTOC(datetime())) 
   fclose(lnfile) 
endproc 
enddefine

In obigem Trivialbeispiel ist in der Klasse nur eine simples Interface in Form der  Methode gettesttime() vorhanden. Diese Methode returniert einen String mit der aktuellen Zeit inkl. Datum.

Registrieren des VFP 6.0 Out of Process OLE Servers

Out of Process OLE Servers werden durch VFP automatisch registriert, wenn Sie das EXE erstellen. Wenn Sie jedoch Ihren OLE Server auf einer anderen Maschine einsetzen müssen, so müssen Sie den OLE Server mit folgendem Befehl (im run Fenster aus Start Menu eingeben):

    Aspexe.exe /regserver

Testen des OLE Servers

Es ist sehr wichtig, dass ein OLE Server getestet wird, bevor man weiterfährt mit der Verwendung. Bei obigem Trivialbeispiel mag das keinen Sinn machen, bei komplizierteren OLE Servern hingegen schon.

Achtung: Es ist ganz wichtig zu wissen, dass jeder VFP OLE Server, unabhängig davon, wo sich die EXE Datei befindet, aus dem WINNT\System32 Verzeichnis aufgestartet wird! Wenn sie also relative Pfadangaben machen, dann immer relativ zu Winnt\System32 oder besser noch explizit (sofern Ihr OLE Serer nur auf ein und derselben Maschine laufen muss). Ansonsten müssen Sie sich über das Setzen des aktuell benötigten Path Gedanken machen.

Test des OLE Servers aus VFP heraus

Aus VFP heraus kann der OLE Server sehr einfach getestet werden:

ox = createobject("aspexe.caspexe") 
?ox.gettesttime() 
release ox

Beachten Sie, dass aspexe der Name der EXE, bzw. des Projektes ist und caspexe der Name der Klasse, welche als OLEPUBLIC deklariert wurde. Release ox gibt die Objektreferenz wieder frei.

Tip: Beachten Sie auch die Art und Weise wie Debugging Informationen herausgeschrieben werden können: Beim Betreiben des OLE Servers werden die Dateien c:\temp\cASPEXE_Init.txt bzw. c:\temp\cASPEXE_Destroy.txt erstellt. Dies kann nützlich sein, wenn der OLE Server abschmiert und man nicht weiss wo er hängen geblieben ist.

[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]