sgcHTML su WebBroker e DataSnap

sgcHTML ti consente di costruire una UI web in Delphi, a partire dai componenti, senza scrivere JavaScript. Fino ad ora quelle pagine giravano sul server sgcWebSockets. Ora puoi servire le stesse pagine da qualsiasi applicazione WebBroker di Embarcadero e dai server DataSnap, così un backend REST esistente può far crescere un front end web completo senza uscire da Delphi. I dettagli, i componenti e il codice si trovano nella nuova pagina WebBroker & DataSnap.

Tutto questo funziona perché sgcHTML è un renderer, non un server. Il livello di componenti e nodi trasforma la tua pagina in una semplice stringa HTML, senza alcuna dipendenza da socket, trasporto o classi server. Quella stringa può essere il corpo di un TWebResponse tanto facilmente quanto può essere la risposta di un server WebSocket, ed è ciò che rende possibili le due integrazioni descritte di seguito.

Qualsiasi applicazione WebBroker

Il componente TsgcHTMX_Engine_Server_WebBroker implementa l'interfaccia standard IWebDispatch. Rilascialo sul tuo TWebModule, oppure chiama il suo DispatchRequest da un TWebActionItem, e servirà la pagina sgcHTML, gli asset CSS e JavaScript integrati e le tue route htmx. Gira su un TIdHTTPWebBrokerBridge standalone, sotto ISAPI, come modulo Apache e come CGI, quindi si adatta a qualsiasi host WebBroker tu abbia già in produzione.

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'interattività usa normali round-trip HTTP di htmx, quindi non serve alcun WebSocket. Se preferisci, è disponibile una modalità classica senza htmx del tutto, con navigazione a pagina intera semplice e post di form standard, che funziona anche con JavaScript disattivato. L'unica cosa che il semplice WebBroker non può fare è il push, perché sotto CGI e ISAPI la richiesta e la risposta possiedono il socket. Per gli aggiornamenti in tempo reale su un host WebBroker semplice, usa il polling di htmx, oppure passa ai bridge server descritti di seguito.

DataSnap, con aggiornamenti in tempo reale su una sola porta

sgcWebSockets include già bridge server drop-in che sostituiscono l'Indy TIdHTTPWebBrokerBridge in un'applicazione DataSnap o WebBroker, così il server acquisisce WebSocket, HTTP/2 o HTTP.sys sulla stessa porta. sgcHTML ora si collega direttamente a essi. Assegna il Server dell'engine al tuo bridge server e la pagina, i suoi asset e il push in tempo reale dei frammenti WebSocket girano tutti sulla stessa porta dei tuoi endpoint 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);

L'engine rivendica solo i propri percorsi, la pagina, gli asset e le tue route. Tutto il resto passa oltre senza essere toccato, quindi il REST /datasnap/* e le azioni già presenti sul tuo TWebModule continuano a funzionare esattamente come prima, e qualsiasi handler OnCommandRequest che hai viene concatenato ed eseguito per primo. Lo stesso schema copre tutti e tre i bridge server: TsgcHTMX_Engine_Server_WebBrokerBridge serve il bridge Indy su HTTP/1.1 e il bridge HTTP/2, mentre TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge serve il bridge HTTP.sys.

Un backend, due volti

La conseguenza piacevole dell'hosting su DataSnap è che un unico insieme di metodi server può svolgere una doppia funzione. Il tuo TDSServerModule è la tua API REST e JSON su /datasnap/rest per qualsiasi client esterno, ed è anche la fonte dati da cui le tue pagine sgcHTML eseguono il rendering in-process. Scrivi la logica di business una sola volta e ottieni sia un'API per macchine sia una UI web per persone, su un solo server, su una sola porta.

Tre demo da cui partire

Il prodotto include tre demo che costruiscono la stessa piccola applicazione in stili diversi, così puoi scegliere quella più adatta al tuo progetto:

• Demos\60.HTML\11.WebBroker, un'applicazione WebBroker con un backend DataSnap e interattività htmx, sia in versione standalone che ISAPI.
• Demos\60.HTML\12.WebBrokerHTML, la stessa applicazione nello stile classico plain-HTML, senza htmx, con navigazione a pagina intera e post di form standard, sempre con un backend DataSnap.
• Demos\40.DataSnap\Server_Indy_HTTP_HTML, una dashboard sgcHTML in tempo reale che si aggiorna da sola tramite WebSocket mentre i metodi REST DataSnap rispondono sulla stessa porta.

Requisiti e disponibilità

L'engine WebBroker supporta da Delphi 7 a Delphi 13. Il percorso del bridge DataSnap richiede un'edizione di Delphi che includa DataSnap, ovvero Enterprise o Architect. WebBroker e DataSnap sono framework di Delphi e C++Builder, quindi questa modalità di hosting è specifica di questi due compilatori. Il porting .NET di sgcHTML fa hosting su ASP.NET Core e raggiunge lì lo stesso risultato.

Tutto ciò che è descritto qui è disponibile ora. La descrizione completa, il riferimento dei componenti e gli esempi di codice si trovano nella pagina WebBroker & DataSnap.

Domande, feedback o aiuto per collegare sgcHTML al tuo server DataSnap? Contattaci. Riceverai una risposta dalle persone che hanno scritto il codice.