sgcHTML auf WebBroker & DataSnap | sgcHTML | eSeGeCe

sgcHTML auf WebBroker & DataSnap

sgcHTML ist nicht an den sgcWebSockets-Server gebunden. Seine Komponenten- und Node-Ebene erzeugt reine HTML-Strings, die von jedem Transport unabhängig sind, sodass dieselben Seiten, die du für den sgcWebSockets-HTTP-Server baust, aus einer Embarcadero-WebBroker-Anwendung und aus einem DataSnap-Server ausgeliefert werden können. Platziere eine Engine-Komponente auf deinem Web-Modul oder weise sie einem Bridge-Server zu, und deine DataSnap-REST-API und deine sgcHTML-Web-UI laufen nebeneinander auf einem Port.

Standard-IWebDispatch
DataSnap auf einem Port
ISAPI / Apache / CGI / HTTP.sys
HTTP/1.1 & HTTP/2
Delphi 7 bis 13
Kostenlose Testversion herunterladen Komponenten durchsuchen
EIN RENDERER, KEIN SERVER

Von Grund auf host-unabhängig

sgcHTML ist ein serverseitiger HTML-Renderer. Jede Komponente und jede Node gibt Standard-Bootstrap-5-Markup als reinen String aus, ohne Abhängigkeit von dem Transport, der ihn ausliefert. Überall dort, wo dein Delphi- oder C++ Builder-Code eine HTTP-Antwort schreiben kann, kann er eine sgcHTML-Seite ausliefern. Genau das lässt dieselbe Seite, die du für den sgcWebSockets-Server gebaut hast, unverändert in einer WebBroker-Anwendung oder einem DataSnap-Server laufen.

Reine HTML-Strings

Die Komponenten-Ebene und die Node-Ebene lösen sich beide zu einem string aus Bootstrap-5-Markup auf. Nichts an dieser Ausgabe setzt den sgcWebSockets-Server voraus, sodass du sie aus deinem eigenen Handler in jede beliebige TWebResponse schreiben kannst.

Standard-IWebDispatch

Die WebBroker-Engine implementiert den Standard-Vertrag IWebDispatch. Sie fügt sich wie jede andere automatisch dispatchende Komponente in die normale WebBroker-Dispatch-Kette ein und existiert so neben deinen vorhandenen Actions und Dispatchern.

Läuft überall dort, wo WebBroker läuft

Da es sich um ganz normales WebBroker handelt, kann eine sgcHTML-Seite aus einem eigenständigen TIdHTTPWebBrokerBridge, einem ISAPI-Modul, einem Apache-Modul, einer CGI-Anwendung oder einem HTTP.sys-Bridge-Server ausgeliefert werden. Eine Codebasis, mehrere Deployment-Formen.

ZWEI INTEGRATIONSWEGE

Wähle den Host, der zu deiner App passt

Es gibt zwei Wege, sgcHTML außerhalb des sgcWebSockets-Servers auszuliefern. Reines WebBroker bietet dir die größte Reichweite, von CGI bis ISAPI. Der Bridge-Server-Pfad ergänzt Live-WebSocket-Push und teilt sich einen Port mit DataSnap.

1. Jede WebBroker-Anwendung

TsgcHTMX_Engine_Server_WebBroker implementiert das Standard-IWebDispatch. Platziere es mit dem Web-Modul als Owner auf deinem TWebModule, oder rufe sein DispatchRequest aus einem TWebActionItem auf, wenn zuerst die Action-Liste laufen soll. So oder so liefert es die sgcHTML-Seite, die eingebauten CSS- und JavaScript-Assets sowie die HTMX-HTTP-Routes aus, die du auf seinem Router registrierst. Es läuft auf einem eigenständigen TIdHTTPWebBrokerBridge, einem ISAPI-Modul, einem Apache-Modul und CGI.

Interaktivität läuft hier über Standard-HTMX per einfacher HTTP-Round-Trips, sodass kein WebSocket nötig ist. Auch ein klassischer Reines-HTML-Modus wird unterstützt, ganz ohne HTMX, mit Vollseiten-Navigation und Standard-Formular-Posts, für Hosts und Seiten, bei denen du nichts als Markup willst. Ein Punkt, den du einplanen solltest: Unter reinem WebBroker, CGI oder ISAPI gibt es keinen WebSocket-Push, weil der Lebenszyklus von Anfrage und Antwort den Socket besitzt. Wenn du auf diesem Weg Live-Updates brauchst, nutze HTMX-Polling oder wechsle zu den Bridge-Servern weiter unten.

2. DataSnap und die Bridge-Server, mit Echtzeit

TsgcHTMX_Engine_Server_WebBrokerBridge zielt auf die sgcWebSockets-WebBroker-Bridge-Server, TsgcWSHTTPWebBrokerBridgeServer über HTTP/1.1 und TsgcWSHTTP2WebBrokerBridgeServer über HTTP/2. TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge zielt auf TsgcWSServer_HTTPAPI_WebBrokerBridge auf HTTP.sys. Du weist die Server-Eigenschaft der Engine deinem Bridge-Server zu, und die sgcHTML-Seite, ihre Assets und der Live-WebSocket-Fragment-Push über BroadcastFragment laufen alle auf demselben Port wie deine DataSnap-REST-Endpunkte.

Die Engine beansprucht nur ihre eigenen Pfade, sodass /datasnap/*-REST-Aufrufe und deine vorhandenen TWebModule-Actions genau wie zuvor weiterlaufen. Jeder OnCommandRequest-Handler, den du bereits zugewiesen hast, wird verkettet, und dein Handler läuft zuerst, sodass nichts von dem, was du gebaut hast, übernommen wird.

EIN BACKEND, ZWEI OBERFLÄCHEN

Deine DataSnap-Methoden sind zugleich die API und die Seitendaten

Dieselben DataSnap-Servermethoden können zwei Zielgruppen zugleich bedienen. Ein TDSServerModule ist deine REST- und JSON-API unter /datasnap/rest/... für externe Clients, und es ist zugleich die Datenquelle, aus der deine sgcHTML-Seiten rendern, in-process, auf demselben Server. Du schreibst die Geschäftslogik einmal und erreichst sie dann aus einem Browser-Fragment und von einem externen REST-Aufrufer über eine gemeinsame Klasse.

REST- / JSON-API

Externe Clients rufen deine Servermethoden unter /datasnap/rest/TServerMethods/<Method>/... genau so auf, wie ein Standard-DataSnap-WebBroker-Server sie bereitstellt. Die sgcHTML-Engine lässt diese Pfade unberührt.

Servergerenderte Seitendaten

Deine Route- und Action-Handler rufen genau dieselbe Servermethoden-Klasse in-process auf, lesen das Ergebnis und übergeben es an sgcHTML-Komponenten. Die Seite rendert aus demselben Backend, das auch deine REST-API beantwortet.

Live-Push, gleicher Port

Auf dem Bridge-Server-Pfad pusht BroadcastFragment neues HTML über WebSockets an jeden verbundenen Browser, auf demselben Port und im selben Prozess wie deine DataSnap-Endpunkte. Dashboards und Monitore aktualisieren sich in dem Moment, in dem sich deine Daten ändern.

SCHNELLSTART

Verbinde die Engine mit deinem Host

Erzeuge die Engine, gib ihr einen Router und eine Seite und weise sie einem Bridge-Server für den DataSnap- und Echtzeit-Pfad zu, oder platziere sie für den Reines-WebBroker-Pfad auf dem Web-Modul.

uses
  Web.HTTPApp, sgcWebSocket_Server_WebBrokerBridge,
  sgcHTMX_Engine_Server_WebBrokerBridge, sgcHTMX_Router;

// === DataSnap + realtime: sgcHTML on the SAME port as the DataSnap REST API ===
FServer := TsgcWSHTTPWebBrokerBridgeServer.Create(Self);
FServer.Port := 8080;

// a router holds the HTMX fragment routes (GET / POST round-trips)
FRouter := TsgcHTMX_Router.Create(Self);
oRoute := FRouter.Routes.Add;
oRoute.Path := '/dashboard/refresh';
oRoute.OnRoute := OnDashboardRefresh;

// the engine claims its own page, assets and routes; DataSnap keeps /datasnap/*
FEngine := TsgcHTMX_Engine_Server_WebBrokerBridge.Create(Self);
FEngine.Router := FRouter;
FEngine.Template.Title := 'DataSnap Realtime Dashboard';
FEngine.Template.BodyContent := BuildDashboard;   // page built from components
FEngine.Server := FServer;                         // share the DataSnap port

FServer.Active := True;

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

// === Plain WebBroker: drop the engine on the TWebModule (standard IWebDispatch) ===
FEngine := TsgcHTMX_Engine_Server_WebBroker.Create(WebModule1);  // Owner = WebModule
FEngine.Router := FRouter;
// includes: sgcWebSocket_Server_WebBrokerBridge.hpp,
//           sgcHTMX_Engine_Server_WebBrokerBridge.hpp, sgcHTMX_Router.hpp

// === DataSnap + realtime: sgcHTML on the SAME port as the DataSnap REST API ===
FServer = new TsgcWSHTTPWebBrokerBridgeServer(this);
FServer->Port = 8080;

// a router holds the HTMX fragment routes (GET / POST round-trips)
FRouter = new TsgcHTMX_Router(this);
TsgcHTMX_Route *oRoute = FRouter->Routes->Add();
oRoute->Path = "/dashboard/refresh";
oRoute->OnRoute = OnDashboardRefresh;

// the engine claims its own page, assets and routes; DataSnap keeps /datasnap/*
FEngine = new TsgcHTMX_Engine_Server_WebBrokerBridge(this);
FEngine->Router = FRouter;
FEngine->Template->Title = "DataSnap Realtime Dashboard";
FEngine->Template->BodyContent = BuildDashboard();   // page built from components
FEngine->Server = FServer;                           // share the DataSnap port

FServer->Active = true;

// push a live HTML fragment to every connected browser over WebSockets
FEngine->BroadcastFragment(BuildStatsFragment());

// === Plain WebBroker: drop the engine on the TWebModule (standard IWebDispatch) ===
FEngine = new TsgcHTMX_Engine_Server_WebBroker(WebModule1);  // Owner = WebModule
FEngine->Router = FRouter;
// WebBroker and DataSnap are Delphi and C++ Builder (VCL) frameworks.
// .NET has no WebBroker and no DataSnap, so this hosting path is specific
// to Delphi and C++ Builder. The sgcHTML .NET port hosts on ASP.NET Core.

using esegece.sgcHTML;
using esegece.sgcHTML.AspNetCore;

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// the sgcHTML.AspNetCore adapter maps the same component-built page
// onto an ASP.NET Core endpoint (Kestrel / IIS), the .NET equivalent
// of the WebBroker host used in Delphi and C++ Builder.
app.UseSgcHtml(engine =>
{
    engine.MapPage("/", () => BuildDashboard());
});

app.Run();
LAUFFÄHIGE DEMOS

Drei Demos werden mit dem Produkt ausgeliefert

Jeder der obigen Wege ist eine vollständige, lauffähige Demo in der sgcWebSockets-Distribution, sodass du von einem Projekt aus starten kannst, das bereits baut und dispatcht.

WebBroker + DataSnap, HTMX

Demos\60.HTML\11.WebBroker ist ein Mini-CRM auf WebBroker mit einem DataSnap-Backend und voller HTMX-Interaktivität und zeigt, wie sich Engine, DataSnap-REST und Standard-WebModule-Actions ein Web-Modul teilen.

Klassisches reines HTML, ohne HTMX

Demos\60.HTML\12.WebBrokerHTML liefert dieselbe Art von Seiten im klassischen Reines-HTML-Modus aus, mit Vollseiten-Navigation und Standard-Formular-Posts über ein DataSnap-Backend und ganz ohne HTMX.

Echtzeit-Dashboard auf einem Port

Demos\40.DataSnap\Server_Indy_HTTP_HTML betreibt ein Live-sgcHTML-Dashboard neben DataSnap auf einem einzigen Port und pusht Statistik-, Diagramm- und Log-Fragmente über WebSockets an jeden Browser.

VORAUSSETZUNGEN

Was du brauchst

Die Engine-Units werden mit sgcHTML ausgeliefert, sodass für keinen der beiden Wege etwas zusätzlich installiert werden muss.

Reines-WebBroker-Pfad

TsgcHTMX_Engine_Server_WebBroker unterstützt Delphi 7 bis Delphi 13. WebBroker ist in jeder RAD Studio Edition verfügbar, und dieselbe Engine ist in C++ Builder verfügbar.

DataSnap-Bridge-Pfad

Die DataSnap-Bridge-Server und die /datasnap/*-REST-Schicht erfordern eine Delphi-Edition, die DataSnap enthält, also Enterprise oder Architect. Die sgcHTML-Seite der Verdrahtung ist auf beiden Wegen dieselbe.

Bestes Preis-Leistungs-Verhältnis: All-AccessAlle eSeGeCe-Produkte, inklusive Premium-Support, ab €1,059 pro Jahr.
All-Access-Preise ansehen

Füge deinem WebBroker- oder DataSnap-Server eine Web-UI hinzu

Liefere Echtzeit-Bootstrap-5-Seiten aus der WebBroker-Anwendung oder dem DataSnap-Server aus, den du bereits betreibst, mit derselben Komponenten-API, die du überall sonst in sgcHTML verwendest.

Kostenlose Testversion herunterladen Komponenten durchsuchen