Migreer van uniGUI naar sgcHTML — Delphi web-UI-componenten | eSeGeCe

Migreer van uniGUI naar sgcHTML

uniGUI van FMSoft is een commercieel Delphi-webframework met een groot visueel palet en een design-time ervaring die dicht bij native VCL-ontwikkeling ligt, en veel teams hebben er serieuze applicaties mee opgeleverd. Teams beginnen meestal naar sgcHTML te kijken wanneer ze lichtere pagina's willen op basis van gewone Bootstrap 5-markup in plaats van een meegeleverd JavaScript-applicatieframework, wanneer componentstatus per sessie in het server-RAM een onderwerp voor capaciteitsplanning wordt, of wanneer ze WebSocket-realtime en een .NET-optie uit dezelfde componentenset willen. sgcHTML houdt je in Object Pascal en RAD Studio en verandert alleen hoe de pagina's worden geproduceerd.

ARCHITECTUUR

Wat er architectonisch verandert

De twee frameworks lossen het browser-UI-probleem op verschillende manieren op. Hier is het feitelijke verschil, en daarna wat het sgcHTML-model je oplevert.

In uniGUI worden applicaties gebouwd in de RAD Studio-formulierontwerper met DB-aware controls en in de browser gerenderd via een meegeleverde Sencha Ext JS-laag. Sessies zijn stateful: elke gebruiker houdt de volledige componentstatus in het server-RAM vast, dus drukke applicaties vragen geheugenplanning en sessiebeheer. sgcHTML kiest een andere route: jouw Delphi- (of C++ Builder- of C#-)code rendert standaard Bootstrap 5-HTML op de server, de browser blijft interactief via htmx, en elk verzoek is stateless tenzij jij ervoor kiest status bij te houden.

Bootstrap 5 plus htmx aan de clientzijde

Geen meegeleverd JavaScript-applicatieframework van derden. De clientzijde is Bootstrap 5 plus htmx (~14 KB), dus pagina's zijn lichter en laden snel op elk apparaat.

Gewone HTML die jij beheerst

De output is standaard server-rendered HTML die je in de browser kunt inspecteren en met elk Bootstrap 5-thema kunt herstylen, met licht en donker thema ingebouwd, in plaats van een Ext JS-look.

Standaard stateless

Geen volledige componentstatus per sessie in het server-RAM als standaard. Jij bepaalt welke sessiedata je bijhoudt, wat capaciteitsplanning en herstarts vereenvoudigt.

Realtime en bereik ingebouwd

WebSocket-push komt uit dezelfde componentenset via de sgcHTMX-engine, en dezelfde Tsgc*-API is beschikbaar in Delphi, C++ Builder en een puur managed .NET-implementatie.

CONCEPTMAPPING

uniGUI-concepten en hun sgcHTML-equivalenten

De bouwblokken laten zich netjes mappen. Dit is de vertaaltabel die je team scherm voor scherm zal gebruiken.

uniGUI-concept	sgcHTML-equivalent
uniForm / uniFrame	sgcHTML-pagina- en paneelcompositie opgebouwd uit node-componenten
DB-aware grids en edits	Data-aware TsgcHTMLComponent_Grid / TsgcHTMLComponent_Form rechtstreeks gekoppeld aan een TDataSet
Ext JS-clientlaag	Bootstrap 5-markup plus htmx (~14 KB)
Ajax-events	htmx-fragmentroutes die component-HTML retourneren
Sessiebeheer en RAM-status per gebruiker	Stateless rendering plus de sessiedata die jij kiest te bewaren
Ext-theming	Elk Bootstrap 5-thema, met licht en donker thema ingebouwd
uniGUI Server- / HyperServer-deployment	Eén sgcWebSockets-serverbinary, of een WebBroker-, DataSnap- of RAD Server-host
Polling en push-extensies	sgcHTMX WebSocket-broadcast van HTML-fragmenten (hx-swap-oob)

WAT JE BEHOUDT

De migratie verandert minder dan je denkt

De overstap naar sgcHTML vervangt de UI-laag, niet je investering.

Je codebase en IDE

Je blijft in RAD Studio met Delphi of C++ Builder. sgcHTML-componenten zijn native klassen die in je serverbinary worden gecompileerd, met volledige broncode inbegrepen.

Je datamodules

Je TDataSet-logica, query's en businessregels gaan ongewijzigd mee. 28 van de 93 componenten zijn data-aware en koppelen rechtstreeks aan een TDataSet of DataSource.

Je deploymentgewoonten

Je blijft één zelfstandige executable of service uitleveren, zonder externe runtime die je ernaast moet installeren.

De vaardigheden van je team

Jij schrijft Object Pascal of C#; sgcHTML schrijft de HTML, CSS en JavaScript. Er is geen JavaScript van de ontwikkelaar vereist.

MIGRATIEPAD

Een pragmatisch migratiepad

Je hoeft niet alles tegelijk te migreren. Vier stappen die teams in de praktijk volgen.

Inventariseer de schermen

Maak een lijst van elke uniForm en uniFrame, de datasets erachter, en welke schermen live data nodig hebben. Deze inventaris stuurt het hele plan.

Map schermen naar componenten

Koppel elk scherm aan sgcHTML-componenten met behulp van de concepttabel hierboven en de componentgalerij: grids, formulieren, grafieken, dashboards en meer.

Herbouw pagina voor pagina

Beide servers kunnen naast elkaar draaien achter dezelfde reverse proxy, omdat sgcHTML standaard HTTP serveert. Verplaats één scherm tegelijk en laat de rest op uniGUI tot het klaar is.

Sluit interacties en push aan

Voeg htmx-interacties toe voor gedeeltelijke updates, en WebSocket-push via de sgcHTMX-engine overal waar de applicatie live data nodig heeft.

MIGRATIESERVICE

Wij helpen je migreren

Je hoeft dit niet alleen te doen. Vertel ons over je uniGUI-applicatie, de schermen, de data erachter en het realtime-gedrag dat je nodig hebt, en het eSeGeCe-team helpt je de migratie te plannen: een componentmapping, een realistische volgorde en een inschatting van de inspanning.

Als je liever hebt dat wij het doen, herbouwen we de applicatie voor je via sgcCustomization HTML: eenmalige pakketten vanaf €149, waarbij ons team de complete webapplicatie bouwt op basis van een schriftelijke beschrijving en een project oplevert dat jij compileert, deployt en doorontwikkelt.

Vraag migratiehulp aan sgcCustomization HTML

Om eerlijk te zijn: bij uniGUI blijven is een redelijke keuze wanneer een diepgaande RAD-formulierontwerper en een desktopachtige interface belangrijker zijn dan stateless schalen, en wanneer het aantal gelijktijdige gebruikers begrensd en ingepland is. Wil je het volledige beeld voordat je beslist, lees dan onze neutrale zij-aan-zij-matrix met bronvermeldingen, waar elke claim naar de eigen documentatie van elke leverancier linkt.

ZIE HET DRAAIEN