sgcHTML Design Surface — Créer des pages visuellement, pas seulement en code | eSeGeCe Blog

sgcHTML Design Surface — Créer des pages visuellement, pas seulement en code

· Composants

sgcWebSockets 2026.9.0 ajoute une nouvelle façon de construire des pages sgcHTML : le Design Surface. Jusqu'à présent, chaque page était composée en code — créer les composants, définir leurs propriétés, lire le HTML résultant. Cela fonctionne toujours, et reste la méthode principale pour construire une page. Ce qui est nouveau, c'est une seconde voie, visuelle : déposer les mêmes composants directement sur un formulaire VCL ordinaire, les disposer, ajuster leurs propriétés dans l'Object Inspector, et générer la page identique à celle que vous auriez autrement écrite à la main.

Deux façons de construire une page

L'approche à l'exécution n'a pas changé. Créez ou déposez les composants, définissez leurs propriétés et liez les données en code Pascal, C# ou .NET, puis lisez la propriété HTML du composant :

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;

Le Design Surface ajoute une seconde option pour les mêmes composants : les déposer sur un formulaire, et laisser la structure de la page provenir de la disposition du formulaire lui-même plutôt que d'appels au constructeur.

Le Design Surface

La position et la largeur d'un composant sur le formulaire déterminent sa ligne et sa colonne Bootstrap, et ses propriétés publiées sont ajustées dans l'Object Inspector plutôt qu'en code. Un composant TsgcHTMLDesignSurface ajouté au formulaire lit cette disposition. Appelez sgcHTMLDesignBuildFromControls une fois, généralement au démarrage, pour parcourir les composants déposés sur le formulaire et les intégrer à l'arbre de nœuds du surface, puis lisez Surface.GetBodyHTML pour le générer :

uses
  sgcHTMLDesign_Surface;

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

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

Pour le balisage que la palette de composants ne couvre pas, Surface.AddHTML ajoute un nœud HTML fixe dans le même arbre, positionné via la propriété Order du nœud, ou inséré dans le corps d'un composant déposé avec Slot := 'Body'.

Mêmes composants, même résultat

Le Design Surface ne change que la façon dont la structure d'une page est exprimée, pas les composants eux-mêmes ni leur comportement. Un composant déposé sur un formulaire conçu visuellement est une instance de composant ordinaire — Grid1.LoadFromDataSet(qry) fonctionne exactement comme il le ferait sur une page entièrement construite en code. Les deux styles de conception peuvent aussi être librement mélangés sur une même page, et tous deux produisent des composants qui compilent et s'exécutent de façon identique une fois construits.

Quand utiliser chaque approche

La composition à l'exécution reste la mieux adaptée lorsque la structure d'une page est elle-même dynamique ou pilotée par les données — lignes générées en boucle, sections conditionnelles, contenu dépendant d'un état connu seulement à l'exécution — et pour une source unique partagée entre Delphi 7–13 sans dépendance à l'IDE. Le Design Surface convient le mieux pour disposer visuellement une structure de page majoritairement statique, voir la forme de la page pendant sa construction, et ajuster les propriétés via l'Object Inspector plutôt qu'en code. Aucune des deux n'introduit de différence au niveau des capacités d'exécution : le choix de l'une ou l'autre est purement une préférence de conception.

Encore en évolution

La palette de composants du Design Surface s'étend activement, et quelques lacunes subsistent aujourd'hui. Le balisage d'habillage propre à certains composants, comme la coque de carte de TsgcHTMLComponent_Panel, n'a pas encore de propriété permettant de le supprimer. Les champs de TsgcHTMLComponent_Form n'appliquent pas actuellement les classes ou les étendues de colonnes comme peut le faire un balisage écrit à la main. Toutes les propriétés n'existent pas sur chaque composant apparenté — UseColorClass, par exemple, existe sur Panel mais pas sur Login ni StatCard. Et TsgcHTMLComponent_Grid n'expose pas encore les en-têtes de colonnes triables comme propriété de conception. Rien de tout cela n'affecte le chemin d'exécution, et la palette continue de combler ces lacunes à chaque version.

Le voir en action

La façon la plus claire de comparer les deux approches côte à côte est le dossier Demos\60.HTML livré avec sgcWebSockets. 01.RunTime contient les démos originales, construites en code ; 02.DesignTime contient chacune d'entre elles — AdminCRUD, LiveMonitor, Portal, HTMX, Grid, Site, Components, Helpdesk, ShopAssistant, WebBroker et WebBrokerHTML, ainsi que la démo ERP qui a lancé le modèle — entièrement reconstruites sur des formulaires avec le Design Surface. Comparez les deux dossiers pour une même démo et vous obtenez la même page issue de deux styles de conception différents.

Mise à niveau

Le Design Surface fait partie du pack sgcHTML dans sgcWebSockets 2026.9.0, sans migration nécessaire pour les pages existantes construites à l'exécution. Téléchargez la version d'essai gratuite pour l'essayer, et parcourez l'ensemble des composants sur le hub des composants.

Des questions, des retours ou besoin d'aide pour la migration ? Contactez-nous — vous obtiendrez une réponse des personnes qui ont écrit le code.