sgcHTML sur WebBroker & DataSnap | sgcHTML | eSeGeCe

sgcHTML sur WebBroker & DataSnap

sgcHTML n'est pas lié au serveur sgcWebSockets. Sa couche composant et sa couche nœud produisent de simples chaînes HTML indépendantes de tout transport, si bien que les mêmes pages que tu construis pour le serveur HTTP sgcWebSockets peuvent être servies depuis une application Embarcadero WebBroker et depuis un serveur DataSnap. Pose un composant moteur sur ton module web, ou assigne-le à un serveur passerelle, et ton API REST DataSnap et ton interface web sgcHTML tournent côte à côte sur un seul port.

IWebDispatch standard
DataSnap sur un seul port
ISAPI / Apache / CGI / HTTP.sys
HTTP/1.1 & HTTP/2
Delphi 7 à 13
Télécharger l'essai gratuit Parcourir les composants
UN MOTEUR DE RENDU, PAS UN SERVEUR

Indépendant de l'hôte par conception

sgcHTML est un moteur de rendu HTML côté serveur. Chaque composant et chaque nœud émet du balisage Bootstrap 5 standard sous forme de simple chaîne, sans aucune dépendance vis-à-vis du transport qui la délivre. Partout où ton code Delphi ou C++ Builder peut écrire une réponse HTTP, il peut servir une page sgcHTML. C'est ce qui permet à la même page que tu as construite pour le serveur sgcWebSockets de tourner, sans modification, à l'intérieur d'une application WebBroker ou d'un serveur DataSnap.

De simples chaînes HTML

La couche composant et la couche nœud se résolvent toutes deux en une string de balisage Bootstrap 5. Rien dans cette sortie ne présuppose le serveur sgcWebSockets, tu peux donc l'écrire dans n'importe quel TWebResponse depuis ton propre gestionnaire.

IWebDispatch standard

Le moteur WebBroker implémente le contrat IWebDispatch standard. Il s'insère dans la chaîne de répartition WebBroker normale comme n'importe quel autre composant à répartition automatique, il coexiste donc avec tes actions et répartiteurs existants.

Tourne partout où WebBroker tourne

Comme il s'agit de WebBroker ordinaire, une page sgcHTML peut être servie depuis un TIdHTTPWebBrokerBridge autonome, un module ISAPI, un module Apache, un exécutable CGI ou un serveur passerelle HTTP.sys. Une seule base de code, plusieurs formes de déploiement.

DEUX VOIES D'INTÉGRATION

Choisis l'hôte qui convient à ton application

Il y a deux façons de servir sgcHTML en dehors du serveur sgcWebSockets. WebBroker simple t'offre la plus large portée, de CGI à ISAPI. La voie serveur passerelle ajoute le push WebSocket en direct et partage un port avec DataSnap.

1. N'importe quelle application WebBroker

TsgcHTMX_Engine_Server_WebBroker implémente l'IWebDispatch standard. Pose-le sur ton TWebModule avec le module web comme propriétaire, ou appelle son DispatchRequest depuis un TWebActionItem quand tu veux que la liste d'actions s'exécute d'abord. Dans les deux cas, il sert la page sgcHTML, les ressources CSS et JavaScript intégrées, et les routes HTTP HTMX que tu enregistres sur son Router. Il tourne sur un TIdHTTPWebBrokerBridge autonome, un module ISAPI, un module Apache et CGI.

L'interactivité passe ici par du HTMX standard sur de simples allers-retours HTTP, aucun WebSocket n'est donc requis. Un mode HTML classique est également pris en charge, sans aucun HTMX, avec navigation pleine page et envois de formulaires standard, pour les hôtes et les pages où tu ne veux rien d'autre que du balisage. Une réserve à anticiper : sous WebBroker simple, CGI ou ISAPI, il n'y a pas de push WebSocket, car le cycle de vie de la requête et de la réponse possède la socket. Quand tu as besoin de mises à jour en direct sur cette voie, utilise l'interrogation HTMX, ou passe aux serveurs passerelles ci-dessous.

2. DataSnap et les serveurs passerelles, avec le temps réel

TsgcHTMX_Engine_Server_WebBrokerBridge cible les serveurs passerelles WebBroker de sgcWebSockets, TsgcWSHTTPWebBrokerBridgeServer en HTTP/1.1 et TsgcWSHTTP2WebBrokerBridgeServer en HTTP/2. TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge cible TsgcWSServer_HTTPAPI_WebBrokerBridge sur HTTP.sys. Tu assignes la propriété Server du moteur à ton serveur passerelle, et la page sgcHTML, ses ressources et le push de fragments WebSocket en direct via BroadcastFragment tournent tous sur le même port que tes endpoints REST DataSnap.

Le moteur ne revendique que ses propres chemins, de sorte que les appels REST /datasnap/* et tes actions TWebModule existantes continuent de fonctionner exactement comme avant. Tout gestionnaire OnCommandRequest que tu as déjà assigné est chaîné, et ton gestionnaire s'exécute en premier, rien de ce que tu as construit n'est donc supplanté.

UN SEUL BACK-END, DEUX SURFACES

Tes méthodes DataSnap sont à la fois l'API et les données de la page

Les mêmes méthodes de serveur DataSnap peuvent servir deux publics à la fois. Un TDSServerModule est ton API REST et JSON à /datasnap/rest/... pour les clients externes, et c'est aussi la source de données à partir de laquelle tes pages sgcHTML s'affichent, dans le même processus, sur le même serveur. Tu écris la logique métier une seule fois, puis tu l'atteins depuis un fragment de navigateur et depuis un appelant REST externe via une seule classe partagée.

API REST / JSON

Les clients externes appellent tes méthodes de serveur à /datasnap/rest/TServerMethods/<Method>/... exactement comme un serveur DataSnap WebBroker standard les expose. Le moteur sgcHTML laisse ces chemins intacts.

Données de page rendues côté serveur

Tes gestionnaires de route et d'action appellent la même classe de méthodes de serveur dans le même processus, lisent le résultat et le transmettent aux composants sgcHTML. La page s'affiche à partir du back-end identique qui répond à ton API REST.

Push en direct, même port

Sur la voie serveur passerelle, BroadcastFragment pousse du nouveau HTML vers chaque navigateur connecté via WebSockets, sur le même port et le même processus que tes endpoints DataSnap. Tableaux de bord et moniteurs se mettent à jour à l'instant où tes données changent.

DÉMARRAGE RAPIDE

Relie le moteur à ton hôte

Crée le moteur, donne-lui un routeur et une page, puis assigne-le à un serveur passerelle pour la voie DataSnap et temps réel, ou pose-le sur le module web pour la voie WebBroker simple.

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();
DÉMOS FONCTIONNELLES

Trois démos sont livrées avec le produit

Chacune des voies ci-dessus est une démo complète et exécutable dans la distribution sgcWebSockets, tu peux donc partir d'un projet qui compile et répartit déjà.

WebBroker + DataSnap, HTMX

Demos\60.HTML\11.WebBroker est un mini CRM sur WebBroker avec un back-end DataSnap et une interactivité HTMX complète, montrant le moteur, DataSnap REST et les actions WebModule standard partageant un même module web.

HTML classique, sans HTMX

Demos\60.HTML\12.WebBrokerHTML sert le même type de pages en mode HTML classique, avec navigation pleine page et envois de formulaires standard sur un back-end DataSnap, et sans aucun HTMX.

Tableau de bord temps réel sur un seul port

Demos\40.DataSnap\Server_Indy_HTTP_HTML exécute un tableau de bord sgcHTML en direct aux côtés de DataSnap sur un seul port, poussant des fragments de statistiques, de graphiques et de journaux vers chaque navigateur via WebSockets.

PRÉREQUIS

Ce dont tu as besoin

Les unités du moteur sont livrées avec sgcHTML, il n'y a donc rien de plus à installer pour l'une ou l'autre voie.

Voie WebBroker simple

TsgcHTMX_Engine_Server_WebBroker prend en charge Delphi 7 à Delphi 13. WebBroker est disponible dans toutes les éditions de RAD Studio, et le même moteur est disponible en C++ Builder.

Voie passerelle DataSnap

Les serveurs passerelles DataSnap et la couche REST /datasnap/* nécessitent une édition de Delphi qui inclut DataSnap, c'est-à-dire Enterprise ou Architect. Côté sgcHTML, le câblage est le même sur les deux voies.

Meilleur rapport qualité-prix : All-AccessTous les produits eSeGeCe, Support Premium inclus, à partir de €1,059/an.
Voir les tarifs All-Access

Ajoute une interface web à ton serveur WebBroker ou DataSnap

Sers des pages Bootstrap 5 en temps réel depuis l'application WebBroker ou le serveur DataSnap que tu exécutes déjà, avec la même API de composants que tu utilises partout ailleurs dans sgcHTML.

Télécharger l'essai gratuit Parcourir les composants