sgcHTML auf WebBroker und DataSnap

sgcHTML ermöglicht es Ihnen, eine Web-UI in Delphi aus Komponenten zu erstellen, ohne JavaScript schreiben zu müssen. Bisher liefen diese Seiten auf dem sgcWebSockets-Server. Sie können dieselben Seiten jetzt aus jeder Embarcadero-WebBroker-Anwendung und von DataSnap-Servern ausliefern, sodass ein bestehendes REST-Backend ein vollständiges Web-Frontend erhalten kann, ohne Delphi zu verlassen. Die Details, die Komponenten und der Code finden sich auf der neuen Seite WebBroker & DataSnap.

Das funktioniert, weil sgcHTML ein Renderer ist, kein Server. Die Komponenten- und Node-Schicht verwandelt Ihre Seite in eine einfache HTML-Zeichenkette, ohne Abhängigkeit von einer Socket-, Transport- oder Server-Klasse. Diese Zeichenkette kann genauso einfach der Body eines TWebResponse sein wie die Antwort eines WebSocket-Servers, und genau das macht die beiden folgenden Integrationen möglich.

Jede WebBroker-Anwendung

Die Komponente TsgcHTMX_Engine_Server_WebBroker implementiert die Standardschnittstelle IWebDispatch. Platzieren Sie sie auf Ihrem TWebModule oder rufen Sie ihre DispatchRequest-Methode aus einem TWebActionItem auf, und sie liefert die sgcHTML-Seite, die integrierten CSS- und JavaScript-Assets sowie Ihre htmx-Routen aus. Sie läuft auf einer eigenständigen TIdHTTPWebBrokerBridge, unter ISAPI, unter einem Apache-Modul und als CGI, sodass sie zu jedem WebBroker-Host passt, den Sie bereits einsetzen.

uses
  Web.HTTPApp, sgcHTMX_Engine_Server_WebBroker, sgcHTMX_Router;

// Any WebBroker host: the engine's Owner is the web module,
// so the standard WebBroker dispatcher calls it automatically
FEngine := TsgcHTMX_Engine_Server_WebBroker.Create(WebModule1);
FEngine.Router := FRouter;   // your htmx routes and the page

Interaktivität nutzt gewöhnliche htmx-HTTP-Roundtrips, sodass kein WebSocket erforderlich ist. Wenn Sie möchten, gibt es einen klassischen Modus ganz ohne htmx, mit einfacher Ganzseiten-Navigation und Standard-Formular-Posts, der auch bei ausgeschaltetem JavaScript funktioniert. Das Einzige, was reines WebBroker nicht kann, ist Push, denn unter CGI und ISAPI besitzen Anfrage und Antwort den Socket. Für Live-Updates auf einem reinen WebBroker-Host verwenden Sie htmx-Polling oder wechseln Sie zu den Bridge-Servern weiter unten.

DataSnap, mit Live-Updates auf einem Port

sgcWebSockets liefert bereits Drop-in-Bridge-Server mit, die die Indy-TIdHTTPWebBrokerBridge in einer DataSnap- oder WebBroker-Anwendung ersetzen, sodass der Server WebSockets, HTTP/2 oder HTTP.sys auf demselben Port erhält. sgcHTML fügt sich jetzt direkt in sie ein. Weisen Sie die Server-Eigenschaft der Engine Ihrem Bridge-Server zu, und die Seite, ihre Assets und der Live-WebSocket-Fragment-Push laufen alle auf demselben Port wie Ihre DataSnap-REST-Endpunkte.

uses
  sgcWebSocket_Server_WebBrokerBridge,
  sgcHTMX_Engine_Server_WebBrokerBridge, sgcHTMX_Router;

// A DataSnap / WebBroker bridge server
FServer := TsgcWSHTTPWebBrokerBridgeServer.Create(Self);
FServer.Port := 8080;

FEngine := TsgcHTMX_Engine_Server_WebBrokerBridge.Create(Self);
FEngine.Router := FRouter;     // your htmx routes and the page
FEngine.Server := FServer;     // share the DataSnap port
FServer.Active := True;

// push a live HTML fragment to every connected browser
FEngine.BroadcastFragment(BuildStatsFragment);

Die Engine beansprucht nur ihre eigenen Pfade, die Seite, die Assets und Ihre Routen. Alles andere wird unberührt durchgereicht, sodass /datasnap/*-REST und die bereits auf Ihrem TWebModule vorhandenen Aktionen genau wie zuvor weiterarbeiten, und jeder OnCommandRequest-Handler, den Sie haben, wird verkettet und läuft zuerst. Dasselbe Muster gilt für alle drei Bridge-Server: TsgcHTMX_Engine_Server_WebBrokerBridge bedient die Indy-Bridge über HTTP/1.1 und die HTTP/2-Bridge, und TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge bedient die HTTP.sys-Bridge.

Ein Backend, zwei Gesichter

Die schöne Folge des Hostings auf DataSnap ist, dass ein einziger Satz von Servermethoden doppelte Arbeit leisten kann. Ihr TDSServerModule ist Ihre REST- und JSON-API unter /datasnap/rest für jeden externen Client, und es ist zugleich die Datenquelle, aus der Ihre sgcHTML-Seiten prozessintern rendern. Sie schreiben die Geschäftslogik einmal und erhalten daraus sowohl eine Maschinen-API als auch eine menschliche Web-UI, auf einem Server, auf einem Port.

Drei Demos für den Anfang

Das Produkt liefert drei Demos mit, die dieselbe kleine Anwendung in unterschiedlichen Stilen aufbauen, sodass Sie diejenige auswählen können, die zu Ihrem Projekt passt:

• Demos\60.HTML\11.WebBroker, eine WebBroker-Anwendung mit einem DataSnap-Backend und htmx-Interaktivität, sowohl als eigenständiger als auch als ISAPI-Build.
• Demos\60.HTML\12.WebBrokerHTML, dieselbe Anwendung im klassischen reinen HTML-Stil, ohne htmx, mit Ganzseiten-Navigation und Standard-Formular-Posts, wiederum mit einem DataSnap-Backend.
• Demos\40.DataSnap\Server_Indy_HTTP_HTML, ein Echtzeit-sgcHTML-Dashboard, das sich selbst über WebSockets aktualisiert, während die DataSnap-REST-Methoden auf demselben Port antworten.

Voraussetzungen und Verfügbarkeit

Die WebBroker-Engine unterstützt Delphi 7 bis Delphi 13. Der DataSnap-Bridge-Weg benötigt eine Delphi-Edition, die DataSnap enthält, also Enterprise oder Architect. WebBroker und DataSnap sind Delphi- und C++Builder-Frameworks, daher ist dieses Hosting-Szenario auf diese beiden Compiler beschränkt. Der sgcHTML-.NET-Port hostet stattdessen auf ASP.NET Core und erreicht dort dasselbe Ergebnis.

Alles hier Beschriebene ist ab sofort verfügbar. Die vollständige Beschreibung, die Komponentenreferenz und die Codebeispiele finden sich auf der Seite WebBroker & DataSnap.

Fragen, Feedback oder Hilfe beim Einbinden von sgcHTML in Ihren DataSnap-Server? Nehmen Sie Kontakt auf. Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.