sgcHTML sur WebBroker et DataSnap

sgcHTML vous permet de construire une interface web en Delphi, à partir de composants, sans avoir à écrire de JavaScript. Jusqu'à présent, ces pages s'exécutaient sur le serveur sgcWebSockets. Vous pouvez désormais servir les mêmes pages depuis n'importe quelle application Embarcadero WebBroker et depuis des serveurs DataSnap, de sorte qu'un backend REST existant peut se doter d'une interface web complète sans quitter Delphi. Les détails, les composants et le code se trouvent sur la nouvelle page WebBroker & DataSnap.

Cela fonctionne parce que sgcHTML est un moteur de rendu, pas un serveur. La couche de composants et de nœuds transforme votre page en une simple chaîne HTML, sans dépendance à aucune classe de socket, de transport ou de serveur. Cette chaîne peut être le corps d'un TWebResponse tout aussi facilement qu'elle peut être la réponse d'un serveur WebSocket, ce qui rend possibles les deux intégrations ci-dessous.

N'importe quelle application WebBroker

Le composant TsgcHTMX_Engine_Server_WebBroker implémente l'interface standard IWebDispatch. Déposez-le sur votre TWebModule, ou appelez son DispatchRequest depuis un TWebActionItem, et il sert la page sgcHTML, les ressources CSS et JavaScript intégrées, ainsi que vos routes htmx. Il s'exécute sur un TIdHTTPWebBrokerBridge autonome, sous ISAPI, sous un module Apache et en CGI, de sorte qu'il s'adapte à n'importe quel hôte WebBroker que vous déployez déjà.

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

L'interactivité utilise de simples allers-retours HTTP htmx, aucun WebSocket n'est donc nécessaire. Si vous préférez, il existe un mode classique sans htmx du tout, avec navigation en pleine page et envois de formulaires standard, qui fonctionne même lorsque JavaScript est désactivé. La seule chose que le WebBroker simple ne peut pas faire, c'est le push, car sous CGI et ISAPI la requête et la réponse détiennent le socket. Pour des mises à jour en direct sur un hôte WebBroker simple, utilisez le polling htmx, ou passez aux serveurs bridge ci-dessous.

DataSnap, avec des mises à jour en direct sur un seul port

sgcWebSockets fournit déjà des serveurs bridge prêts à l'emploi qui remplacent le TIdHTTPWebBrokerBridge d'Indy dans une application DataSnap ou WebBroker, de sorte que le serveur gagne les WebSockets, HTTP/2 ou HTTP.sys sur le même port. sgcHTML s'y branche désormais directement. Affectez le Server du moteur à votre serveur bridge et la page, ses ressources et le push de fragments WebSocket en direct s'exécutent tous sur le même port que vos points de terminaison REST DataSnap.

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);

Le moteur ne revendique que ses propres chemins, la page, les ressources et vos routes. Tout le reste passe sans être touché, de sorte que le REST /datasnap/* et les actions déjà présentes sur votre TWebModule continuent de fonctionner exactement comme avant, et tout gestionnaire OnCommandRequest que vous avez est chaîné et s'exécute en premier. Le même schéma couvre les trois serveurs bridge : TsgcHTMX_Engine_Server_WebBrokerBridge sert le bridge Indy sur HTTP/1.1 et le bridge HTTP/2, et TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge sert le bridge HTTP.sys.

Un seul backend, deux visages

La belle conséquence de l'hébergement sur DataSnap, c'est qu'un même ensemble de méthodes serveur peut jouer un double rôle. Votre TDSServerModule est votre API REST et JSON à /datasnap/rest pour n'importe quel client externe, et il est aussi la source de données à partir de laquelle vos pages sgcHTML effectuent leur rendu en interne. Vous écrivez la logique métier une seule fois, et vous en obtenez à la fois une API machine et une interface web humaine, sur un seul serveur, sur un seul port.

Trois démos pour démarrer

Le produit est livré avec trois démos qui construisent la même petite application dans différents styles, afin que vous puissiez choisir celle qui correspond à votre projet :

• Demos\60.HTML\11.WebBroker, une application WebBroker avec un backend DataSnap et l'interactivité htmx, à la fois en build autonome et ISAPI.
• Demos\60.HTML\12.WebBrokerHTML, la même application dans le style HTML pur classique, sans htmx, avec navigation en pleine page et envois de formulaires standard, là encore avec un backend DataSnap.
• Demos\40.DataSnap\Server_Indy_HTTP_HTML, un tableau de bord sgcHTML en temps réel qui se met à jour lui-même via les WebSockets pendant que les méthodes REST DataSnap répondent sur le même port.

Prérequis et disponibilité

Le moteur WebBroker prend en charge Delphi 7 à Delphi 13. La voie du bridge DataSnap nécessite une édition Delphi qui inclut DataSnap, c'est-à-dire Enterprise ou Architect. WebBroker et DataSnap sont des frameworks Delphi et C++Builder, ce mode d'hébergement est donc spécifique à ces deux compilateurs. Le portage .NET de sgcHTML s'héberge quant à lui sur ASP.NET Core, et y parvient au même résultat.

Tout ce qui est décrit ici est disponible dès maintenant. L'article complet, la référence des composants et les exemples de code se trouvent sur la page WebBroker & DataSnap.

Des questions, des retours ou besoin d'aide pour intégrer sgcHTML dans votre serveur DataSnap ? Contactez-nous. Vous recevrez une réponse des personnes qui ont écrit le code.