Hallo
MapMan,
heute kommen ich endlich einmal dazu, eine Antwort zu verfassen. Weshalb hat ein Tag eigentlich nur 24 Stunden!?
Erst einmal vielen Dank für das Lob!
Ich fange bei der Beantwortung Deinen Fragen einfach mal von hinten an.
Zitat:
...soweit ich deine Methodik bis jetzt verstehe [...], läuft es grundsätzlich darauf hinaus, über die Klartextbezeichnungen der Javascript-Funktionen an
COM-Interfaces zu gelangen, über welche diese dann angesprochen werden können.
Ja, genau das ist der Kern des Ganzen.
Zitat:
Also werden beim Laden von Javascript-Libraries im WebBrowser "temporäre" Interfaces angelegt ?
Das machen der Internet-Explorer bzw. die JScript-Engine beim Einlesen der
HTML-Seite.
Das "normale" Interface
IDispatch wird bei den meisten Browser-Objekten zu einer
IDispatchEx-
Schnittstelle, die unter anderem das dynamische Hinzufügen und Löschen von Eigenschaften und Methoden beim zugehörigen
COM-Objekt ermöglicht. Da diese Methoden und Eigenschaften im Endeffekt auch nur über ihre ID (DispID) angesprochen werden, könnte das Ganze auf den ersten Blick auch über eine Typbibliothek funktionieren.
Zitat:
Ich kenne den Umgang mit
COM-Objekten nur über das direkte Erzeugen von Typbibliotheken per Import.
Dann habe ich eine Delphi-
Unit zum Ansprechen dieser Objekte.
Das klappt aber leider nur bei statischen Schnittstellen (
IDispatch). Durch die Dynamik des
IDispatchEx-Interfaces ist die Zuordnung der Property-/Methoden-Bezeichnungen zu den DispID's variabel und unterliegt nur der Einschränkung, daß eine einmal vergebene DispID innerhalb des selben Objektes nicht noch einmal vergeben werden darf. Damit scheidet das Konzept der Typbibliothek bei allen JavaScript-Objekten aus.
Zitat:
Aber so "statisch" geht es wohl hier nicht...
Genau!
Möglich wäre noch das Ansprechen von
COM-Objekt-Eigenschaften und -Methoden über (
Ole-)Variant-Variablen mit Interface-Zeigern, wie es zum Beispiel im WebBrowser gemacht wird:
Delphi-Quellcode:
WebBrowser1.OleObject.xxx...
//...
Diese unscheinbare Zeile beinhaltet unheimlich viel "Compilermagie" und funktioniert nicht in allen Fällen und nicht mit allen Compilern.
Um trotzdem die Vorzüge der Delphi-
IDE mit ihrer Codevervollständigung nutzen zu können, sind Delphi-Objekte notwendig, die die
HTML- und JScript-Objekte kapseln. Und genau das ist die grundlegende Idee zu diesem Framework.
Die
Unit DispObject enthält das Basis-Objekt
TDispObject, vom dem
alle anderen Objekte direkt oder indirekt abgeleitet sind. Um einen Mechanismus für die gegenseitige Benachrichtigung zu schaffen, wurde noch
INotifyInterface und seine Implementierung
TNotifyObject geschaffen, das aber nur Delphi-intern Bedeutung besitzt und keine JavaScript-Entsprechung hat.
Die Kopplung der Funktionalität von
TDispObject mit dem
COM-Unterbau erfolgt über die Funktionen in der
Unit BrowserObjects. Damit stellen diese beiden Units das Herzstück dar und alles andere ist - streng genommen - nur eine "Tech-Demo".
Die
Unit JScriptObjects beinhaltet als nächste Stufe die Wrapper für einige grundlegende JavaScript-Objekte, die ihrerseits die Basis sämtlicher Google-Maps-
API-Objekte darstellen.
Bei der Gestaltung dieser Objekte habe ich mich so eng wie möglich an das Google-Maps-
API gehalten und an einigen Stellen lediglich etwas optimiert und "Komfort-Funktionen" hinzugefügt, die dem Delphi-Programmierer den Umgang mit ihnen etwas erleichtern sollen.
Zitat:
Und TScript ist das zentrale Objekt, welches alle Sub-Containerobjekte enthält, also auch alle "Circles"
Das Script-Objekt - genauer genommen
TCustomScript - stellt die Schnittstelle zum Browser-internen JavaScript-Interpreter dar. Würde man mit JavaScript programmieren, wäre das quasi ein impliziter
self-Zeiger. Damit man das Script-Objekt nicht bei jedem Aufruf davorsetzen muß, habe ich in den Demos meisten den folgenden Syntax verwendet:
Delphi-Quellcode:
with Script do
begin
JScriptObject.xxx;
...
end;
Das sieht dann etwas mehr nach JavaScript-Syntax aus...
Das Objekt
TScript ist ein Nachfolger von
TCustomScript und beinhaltet den Zugriff auf den Google-Maps-
API-Namespace - hier speziell das (JavaScript-)Objekt
Google sowie die Delphi-interne Verwaltung der erstellten Karten, Marker und anderer Objekte.
Zitat:
Noch nicht ganz klar ist mir, wo und wie es letztendlich zum Zeichnen des Circles kommt.
Es gibt das
Circle-Objekt. Das ist ein ganz normales JavaScript-Objekt, das um etliche Methoden und Ereignishandler erweitert wurde. Der Konstruktor des Circle-Objektes ist im Google-Maps-
API die Funktion
goggle.maps.Circle(...) (im JScript-Syntax bis auf den Objekt-Namen klein geschrieben). Als JavaScript würde das so aussehen:
Code:
Circle=new google.maps.Circle(...)
Das Schlüsselwort
new konnte ich natürlich nicht in Delphi nachbilden - deshalb wird es hier einfach weggelassen:
Delphi-Quellcode:
Circle:=Google.Maps.Circle(...)
//...
Vielleicht hätte ich eine Funktion
New(ObjectConstructor: TMethod) oder so etwas ähnliches schreiben können - aber das wäre dann doch wohl etwas in Richtung Kanonen und Spatzen abgedriftet...
Zur Erstellung eines Circle-Objektes verwendet das Google-Maps-
API das Objekt
CircleOptions. Auch dafür gibt es einen Delphi-Wrapper:
TCircleOptions.
Dieses Objekt kann direkt angelegt und "gefüllt" werden (einfaches JavaScript-Objekt ohne Google-Maps-Konstruktor):
Delphi-Quellcode:
with Script do
begin
CircleOptions:=TCircleOptions.Create; //Zirkeloptions-Objekt erstellen
CircleOptions.Center:=...
...
end;
Um den Kreis auf der Karte darstellen zu lassen, muß dem Circle-Objekt lediglich das Karten-Objekt zugewiesen werden - alles andere wird JavaScript-intern erledigt:
Delphi-Quellcode:
CircleOptions.Map:=Map_xyz;
//...
Dabei handelt es sich um ein grundlegendes Prinzip aller Wrapper-Objekte: Es werden keine Eigenschaften zwischengespeichert - alle Werte werden direkt aus den zugehörigen JavaScript-Objekten gelesen oder an sie übergeben - sie arbeiten also vollkommen transparent. Nur die Interface-Zeiger und die erstellten Delphi-Objekte werden von den Wrappern verwaltet.
Verwaltungsmäßig wesentlich aufwändiger ist die Umleitung von JavaScript-Ereignissen auf native Delphi-Methoden. Hierbei wird das
External-Objekt des Browsers genutzt. Da beim Aufruf unterschiedliche Parameter übergeben und dynamisch Delphi-Methoden aufgerufen werden müssen, hatte ich anfangs
RTTI-Mechanismen genutzt, die aber alle älteren Delphi-Versionen ausgesperrt hätten. An einigen Stellen im Quelltext ist das noch an den entsprechenden Compiler-Optionen erkennbar. Das wurde aber grundlegend geändert: Das JScript-Objekt
Function macht es möglich. Die Erstellung eines Ereignishandlers erfolgt auf diese Weise:
- Zuweisung einer Delphi-Methode zu einem Wrapper-Ereignis
- Erstellung einer JavasScript-Funktion zum Aufruf der Wrapper-internen Methode
- Registrierung der Wrapper-internen Methode bei der External-Verwaltung
Wird durch ein JavaScript-/
HTML-Objekt ein Ereignis ausgelöst, werden folgende Dinge abgehandelt:
- Abfrage der DispID über das External-Interface
- Aufruf der External-Methode des Wrapper-Objektes über ihre DispID. Dieser Aufruf erfolgt völlig ohne Parameter - dabei gibt es lediglich eine Unterscheidung, ob es sich um eine Funktion oder Prozedur handet (mit oder ohne Rückgabewert).
- Ermittlung der Parameter über das JScript-Funktions-Objekt und Umwandlung in Delphi-interne Objekte
- Aufruf der eigentlichen Delphi-Ereignis-Methode
Zitat:
Ich hab da immer noch das Thema OpenLayers-Framework im Sinn...
Verständlich...
Ich hoffe, daß ich es einigermaßen plausibel ausgedrückt habe: Mit Hilfe der Units JScriptObjects, DispObject und BrowserTools können
sämtliche HTML- und JavaScript-Objekte als Delphi-Wrapper nachgebildet werden - und damit wäre auch das OpenLayers-Framework
ohne Umweg über den Aufruf von JavaScript ansprechbar - etwas Geduld bei der Umsetzung vorausgesetzt...
Die Funktionen
CreatexxxWrapper sind übrigens noch ein Überbleibsel aus "früheren" Tagen: Sie rühren daher, daß die Konstruktoren der JavaScript-Objekte fast immer als
protected deklariert sind. Sie sollen also in der Regel nicht direkt aufgerufen werden. Das wiederum verwirrt den Compiler: Liegt der
protected-Konstruktor beim Aufruf in einer anderen
Unit (auch wenn ein "
Access"-Hilfsobjekt erstellt wurde)
Delphi-Quellcode:
type
TCircleAccess = class(TCircle);
...
TCircleAccess.Create(...)
geht der Schuß zur Laufzeit mitunter nach hinten los.
Das war eine unschöne Zwischenlösung: Da sich die
CreatexxxWrapper-Funktionen im Interface-Abschnitt der Units befinden und damit "öffentlich" zugänglich sind, hätte ich auch gleich die Konstruktoren als
public definieren können...
Das wurde aber inzwischen behoben und wird in der nächsten Version anders gelöst sein.