sgcHTML Design Surface — Seiten visuell erstellen, nicht nur im Code | eSeGeCe Blog

sgcHTML Design Surface — Seiten visuell erstellen, nicht nur im Code

· Komponenten

sgcWebSockets 2026.9.0 führt einen neuen Weg ein, sgcHTML-Seiten zu erstellen: die Design Surface. Bisher wurde jede Seite im Code zusammengestellt — Komponenten erzeugen, ihre Eigenschaften setzen, das resultierende HTML auslesen. Das funktioniert weiterhin und bleibt der primäre Weg, eine Seite zu erstellen. Neu ist ein zweiter, visueller Weg: Platzieren Sie dieselben Komponenten direkt auf einem gewöhnlichen VCL-Formular, ordnen Sie sie an, passen Sie ihre Eigenschaften im Objektinspektor an und erzeugen Sie exakt die Seite, die Sie sonst von Hand geschrieben hätten.

Zwei Wege, eine Seite zu erstellen

Der Laufzeit-Ansatz hat sich nicht geändert. Erzeugen oder platzieren Sie die Komponenten, setzen Sie ihre Eigenschaften und binden Sie Daten in Pascal-, C#- oder .NET-Code, und lesen Sie anschließend die Eigenschaft HTML der Komponente aus:

uses
  sgcHTML_Component_Grid;

var
  oGrid: TsgcHTMLComponent_Grid;
begin
  oGrid := TsgcHTMLComponent_Grid.Create(nil);
  try
    oGrid.Columns.Add.Title := 'Customer';
    oGrid.Columns.Add.Title := 'Total';
    oGrid.Clear;
    oGrid.AddRow(['Acme Corp', '1,240.00']);
    Response.Write(oGrid.HTML);
  finally
    oGrid.Free;
  end;
end;

Die Design Surface fügt für dieselben Komponenten eine zweite Möglichkeit hinzu: Platzieren Sie sie auf einem Formular, und lassen Sie die Struktur der Seite aus dem Layout des Formulars selbst entstehen statt aus Konstruktoraufrufen.

Die Design Surface

Position und Breite einer Komponente auf dem Formular ergeben ihre Bootstrap-Zeile und -Spalte, und ihre published-Eigenschaften werden im Objektinspektor statt im Code angepasst. Eine auf dem Formular platzierte Komponente TsgcHTMLDesignSurface liest dieses Layout aus. Rufen Sie sgcHTMLDesignBuildFromControls einmal auf, typischerweise beim Start, um die auf dem Formular platzierten Komponenten in den Knotenbaum der Surface zu überführen, und lesen Sie dann Surface.GetBodyHTML, um sie zu rendern:

uses
  sgcHTMLDesign_Surface;

procedure TfrmDashboard.Build;
begin
  sgcHTMLDesignBuildFromControls(Surface, Self);
end;

function TfrmDashboard.BodyHTML: string;
begin
  Surface.Invalidate;
  Result := Surface.GetBodyHTML;
end;

Für Markup, das die Komponentenpalette nicht abdeckt, fügt Surface.AddHTML einen festen HTML-Knoten in denselben Baum ein, positioniert über die Eigenschaft Order des Knotens, oder eingebettet in den eigenen Body einer platzierten Komponente mit Slot := 'Body'.

Gleiche Komponenten, gleiche Ausgabe

Die Design Surface ändert nur, wie die Struktur einer Seite ausgedrückt wird, nicht die Komponenten selbst oder ihr Verhalten. Eine auf einem gestalteten Formular platzierte Komponente ist eine ganz gewöhnliche Komponenteninstanz — Grid1.LoadFromDataSet(qry) funktioniert genauso wie auf einer vollständig im Code erstellten Seite. Die beiden Erstellungsstile lassen sich auf derselben Seite auch frei mischen, und beide erzeugen Komponenten, die nach dem Erstellen identisch kompilieren und laufen.

Wann welcher Ansatz sinnvoll ist

Die Erstellung zur Laufzeit passt weiterhin am besten, wenn die Struktur einer Seite selbst dynamisch oder datengetrieben ist — in Schleifen erzeugte Zeilen, bedingte Abschnitte, Inhalte, die von einem erst zur Laufzeit bekannten Zustand abhängen — sowie für eine gemeinsame Quelle über Delphi 7–13 hinweg ohne IDE-Abhängigkeit. Die Design Surface passt am besten, wenn eine größtenteils statische Seitenstruktur visuell angelegt werden soll, die Form der Seite bereits beim Erstellen sichtbar sein soll und Eigenschaften lieber über den Objektinspektor als im Code angepasst werden. In keinem Fall unterscheidet sich die Laufzeitfähigkeit: Die Wahl zwischen beiden ist rein eine Frage der Vorliebe beim Erstellen.

Noch im Wachstum

Die Komponentenpalette der Design Surface wird aktiv erweitert, und heute bestehen noch einige Lücken. Das eigene umschließende Markup mancher Komponenten, etwa die Card-Hülle von TsgcHTMLComponent_Panel, hat noch keine Eigenschaft, um es zu unterdrücken. Felder von TsgcHTMLComponent_Form wenden derzeit keine Spaltenklassen oder -breiten an, wie es handgeschriebenes Markup kann. Nicht jede Eigenschaft existiert bei jeder Schwesterkomponente — UseColorClass etwa gibt es bei Panel, aber nicht bei Login oder StatCard. Und TsgcHTMLComponent_Grid stellt sortierbare Spaltenüberschriften noch nicht als Design-Time-Eigenschaft bereit. Nichts davon betrifft den Laufzeit-Pfad, und die Palette schließt diese Lücken von Release zu Release weiter.

In Aktion sehen

Am klarsten lassen sich beide Ansätze im Ordner Demos\60.HTML vergleichen, der mit sgcWebSockets ausgeliefert wird. 01.RunTime enthält die ursprünglichen, im Code erstellten Demos; 02.DesignTime enthält jede einzelne davon — AdminCRUD, LiveMonitor, Portal, HTMX, Grid, Site, Components, Helpdesk, ShopAssistant, WebBroker und WebBrokerHTML, zusammen mit der ERP-Demo, mit der das Muster begann — vollständig auf Formularen mit der Design Surface neu aufgebaut. Vergleichen Sie die beiden Ordner für dieselbe Demo, und Sie erhalten dieselbe Seite aus zwei unterschiedlichen Erstellungsstilen.

Aktualisieren

Die Design Surface ist Teil des sgcHTML-Pakets in sgcWebSockets 2026.9.0, für bestehende, zur Laufzeit erstellte Seiten ist keine Migration nötig. Holen Sie sich die kostenlose Testversion, um sie auszuprobieren, und werfen Sie einen Blick auf die vollständige Komponentenübersicht im Komponenten-Hub.

Fragen, Feedback oder Hilfe bei der Migration? Nehmen Sie Kontakt auf — Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.