Pełny ERP
Klienci, produkty, fakturowanie, wykresy na pulpicie i logowanie passkey.
Otwórz demo na żywo →
sgcHTML nie jest związany z serwerem sgcWebSockets. Jego warstwa komponentów i węzłów generuje zwykłe ciągi HTML niezależne od jakiegokolwiek transportu, więc te same strony, które budujesz dla serwera HTTP sgcWebSockets, można serwować z aplikacji Embarcadero WebBroker oraz z serwera DataSnap. Umieść jeden komponent silnika w swoim module webowym albo przypisz go do serwera mostkującego, a Twoje REST API DataSnap i interfejs webowy sgcHTML będą działać obok siebie na jednym porcie.
sgcHTML to generator HTML działający po stronie serwera. Każdy komponent i każdy węzeł generuje standardowe znaczniki Bootstrap 5 jako zwykły ciąg znaków, bez zależności od transportu, który go dostarcza. Wszędzie tam, gdzie Twój kod w Delphi lub C++ Builder może zapisać odpowiedź HTTP, może też obsłużyć stronę sgcHTML. To właśnie pozwala tej samej stronie, którą zbudowałeś dla serwera sgcWebSockets, działać bez zmian wewnątrz aplikacji WebBroker lub serwera DataSnap.
Zarówno warstwa komponentów, jak i warstwa węzłów sprowadzają się do string ze znacznikami Bootstrap 5. Nic w tym wyniku nie zakłada serwera sgcWebSockets, więc możesz go zapisać do dowolnego TWebResponse z własnej procedury obsługi.
Silnik WebBroker implementuje standardowy kontrakt IWebDispatch. Podłącza się do zwykłego łańcucha dyspozycji WebBroker jak każdy inny komponent z automatyczną dyspozycją, więc współistnieje z Twoimi istniejącymi akcjami i dyspozytorami.
Ponieważ to zwykły WebBroker, stronę sgcHTML można serwować z samodzielnego TIdHTTPWebBrokerBridge, modułu ISAPI, modułu Apache, pliku wykonywalnego CGI lub serwera mostkującego HTTP.sys. Jedna baza kodu, kilka form wdrożenia.
Są dwa sposoby serwowania sgcHTML poza serwerem sgcWebSockets. Zwykły WebBroker daje najszerszy zasięg, od CGI po ISAPI. Ścieżka z serwerem mostkującym dodaje wypychanie WebSocket na żywo i współdzieli port z DataSnap.
TsgcHTMX_Engine_Server_WebBroker implementuje standardowy IWebDispatch. Umieść go na swoim TWebModule, wskazując moduł webowy jako właściciela, albo wywołaj jego DispatchRequest z TWebActionItem, gdy chcesz, aby najpierw uruchomiła się lista akcji. Tak czy inaczej obsługuje on stronę sgcHTML, wbudowane zasoby CSS i JavaScript oraz trasy HTTP HTMX, które rejestrujesz w jego Router. Działa na samodzielnym TIdHTTPWebBrokerBridge, module ISAPI, module Apache oraz w CGI.
Interaktywność opiera się tu na standardowym HTMX poprzez zwykłe żądania HTTP, więc WebSocket nie jest wymagany. Obsługiwany jest także klasyczny tryb czystego HTML, całkowicie bez HTMX, z nawigacją pełnostronicową i standardowymi wysyłkami formularzy, dla hostów i stron, gdzie chcesz mieć wyłącznie znaczniki. Jedno zastrzeżenie, które warto uwzględnić: przy zwykłym WebBroker, CGI lub ISAPI nie ma wypychania WebSocket, ponieważ cykl życia żądania i odpowiedzi jest właścicielem gniazda. Gdy na tej ścieżce potrzebujesz aktualizacji na żywo, użyj odpytywania HTMX albo przejdź do serwerów mostkujących poniżej.
TsgcHTMX_Engine_Server_WebBrokerBridge jest przeznaczony dla serwerów mostkujących WebBroker z sgcWebSockets: TsgcWSHTTPWebBrokerBridgeServer przez HTTP/1.1 oraz TsgcWSHTTP2WebBrokerBridgeServer przez HTTP/2. TsgcHTMX_Engine_Server_HTTPAPI_WebBrokerBridge jest przeznaczony dla TsgcWSServer_HTTPAPI_WebBrokerBridge na HTTP.sys. Przypisujesz właściwość Server silnika do swojego serwera mostkującego, a strona sgcHTML, jej zasoby oraz wypychanie fragmentów WebSocket na żywo przez BroadcastFragment działają na tym samym porcie co punkty końcowe REST Twojego DataSnap.
Silnik przejmuje wyłącznie własne ścieżki, więc wywołania REST /datasnap/* i Twoje istniejące akcje TWebModule nadal działają dokładnie tak jak wcześniej. Każda przypisana już przez Ciebie procedura obsługi OnCommandRequest jest łączona w łańcuch, a Twoja procedura uruchamia się jako pierwsza, więc nic z tego, co zbudowałeś, nie zostaje przejęte.
Te same metody serwera DataSnap mogą obsłużyć dwie grupy odbiorców naraz. TDSServerModule to Twoje API REST i JSON pod adresem /datasnap/rest/... dla klientów zewnętrznych, a jednocześnie źródło danych, z którego renderują się Twoje strony sgcHTML, w tym samym procesie, na tym samym serwerze. Logikę biznesową piszesz raz, a potem sięgasz do niej z fragmentu w przeglądarce i od zewnętrznego klienta REST przez jedną wspólną klasę.
Klienci zewnętrzni wywołują Twoje metody serwera pod adresem /datasnap/rest/TServerMethods/<Method>/... dokładnie tak, jak udostępnia je standardowy serwer DataSnap WebBroker. Silnik sgcHTML pozostawia te ścieżki nietknięte.
Twoje procedury obsługi tras i akcji wywołują tę samą klasę metod serwera w tym samym procesie, odczytują wynik i przekazują go komponentom sgcHTML. Strona renderuje się z tego samego back-endu, który odpowiada na Twoje API REST.
Na ścieżce z serwerem mostkującym BroadcastFragment wypycha nowy HTML do każdej podłączonej przeglądarki przez WebSocket, na tym samym porcie i w tym samym procesie co punkty końcowe DataSnap. Pulpity i monitory aktualizują się w momencie zmiany danych.
Utwórz silnik, nadaj mu router i stronę, a następnie przypisz go do serwera mostkującego dla ścieżki DataSnap i czasu rzeczywistego albo umieść go na module webowym dla ścieżki zwykłego WebBroker.
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();
Każda z powyższych ścieżek to kompletne, uruchamialne demo w dystrybucji sgcWebSockets, więc możesz zacząć od projektu, który już się kompiluje i dyspozycjonuje żądania.
Demos\60.HTML\11.WebBroker to mini CRM na WebBroker z back-endem DataSnap i pełną interaktywnością HTMX, pokazujące silnik, REST DataSnap oraz standardowe akcje WebModule współdzielące jeden moduł webowy.
Demos\60.HTML\12.WebBrokerHTML serwuje ten sam rodzaj stron w klasycznym trybie czystego HTML, z nawigacją pełnostronicową i standardowymi wysyłkami formularzy nad back-endem DataSnap, całkowicie bez HTMX.
Demos\40.DataSnap\Server_Indy_HTTP_HTML uruchamia działający na żywo pulpit sgcHTML obok DataSnap na jednym porcie, wypychając fragmenty statystyk, wykresów i logów do każdej przeglądarki przez WebSocket.
Moduły silnika są dostarczane z sgcHTML, więc dla żadnej ze ścieżek nie trzeba instalować niczego dodatkowego.
TsgcHTMX_Engine_Server_WebBroker obsługuje Delphi od 7 do 13. WebBroker jest dostępny w każdej edycji RAD Studio, a ten sam silnik jest dostępny w C++ Builder.
Serwery mostkujące DataSnap oraz warstwa REST /datasnap/* wymagają edycji Delphi zawierającej DataSnap, czyli Enterprise lub Architect. Strona sgcHTML tej konfiguracji jest taka sama na obu ścieżkach.
Te aplikacje serwują swój HTML z Delphi. To samo podejście wchodzi wprost do istniejącej usługi WebBroker lub DataSnap.
Klienci, produkty, fakturowanie, wykresy na pulpicie i logowanie passkey.
Otwórz demo na żywo →
Metryki wypychane do fragmentów htmx out-of-band w momencie zmiany.
Otwórz demo na żywo →
Strefa samoobsługowa za logowaniem, korzystająca z tego samego zestawu komponentów.
Otwórz demo na żywo →