sgcWebSockets 2026.9.0은 sgcHTML 페이지를 만드는 새로운 방법인 디자인 서페이스를 추가해요. 지금까지는 모든 페이지를 코드로 구성했어요 — 컴포넌트를 생성하고, 속성을 설정하고, 결과 HTML을 읽는 방식이었죠. 이 방식은 여전히 동작하고, 페이지를 만드는 주된 방법으로 남아 있어요. 새로 추가된 것은 두 번째 시각적 경로예요. 동일한 컴포넌트를 일반 VCL 폼에 직접 배치하고, 배열하고, 오브젝트 인스펙터에서 속성을 조정하면 직접 코드로 작성했을 때와 동일한 페이지가 렌더링돼요.
페이지를 만드는 두 가지 방법
런타임 방식은 변경되지 않았어요. Pascal, C# 또는 .NET 코드에서 컴포넌트를 생성하거나 배치하고, 속성을 설정하고 데이터를 바인딩한 다음 컴포넌트의 HTML 속성을 읽으면 돼요:
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;
디자인 서페이스는 동일한 컴포넌트에 두 번째 옵션을 추가해요. 컴포넌트를 폼에 배치하면, 페이지 구조가 생성자 호출이 아니라 폼 자체의 레이아웃에서 나오게 돼요.
디자인 서페이스
폼 위 컴포넌트의 위치와 너비로 부트스트랩 행과 열이 결정되고, published 속성은 코드가 아니라 오브젝트 인스펙터에서 조정해요. 폼에 추가된 TsgcHTMLDesignSurface 컴포넌트가 이 레이아웃을 읽어요. 보통 시작 시점에 sgcHTMLDesignBuildFromControls를 한 번 호출해서 폼에 배치된 컴포넌트들을 서페이스의 노드 트리로 옮기고, Surface.GetBodyHTML을 읽어 렌더링해요:
uses
sgcHTMLDesign_Surface;
procedure TfrmDashboard.Build;
begin
sgcHTMLDesignBuildFromControls(Surface, Self);
end;
function TfrmDashboard.BodyHTML: string;
begin
Surface.Invalidate;
Result := Surface.GetBodyHTML;
end;
컴포넌트 팔레트가 다루지 않는 마크업이 필요하다면, Surface.AddHTML로 동일한 트리에 고정 HTML 노드를 추가할 수 있어요. 노드의 Order 속성으로 위치를 지정하거나, Slot := 'Body'로 배치된 컴포넌트 자체의 본문 안에 슬롯으로 넣을 수도 있어요.
동일한 컴포넌트, 동일한 출력
디자인 서페이스는 페이지 구조를 표현하는 방식만 바꿀 뿐, 컴포넌트 자체나 그 동작은 바꾸지 않아요. 디자인된 폼에 배치된 컴포넌트는 평범한 컴포넌트 인스턴스예요 — Grid1.LoadFromDataSet(qry)는 완전히 코드로 만든 페이지에서와 똑같이 동작해요. 두 가지 작성 방식은 같은 페이지에서 자유롭게 섞어 쓸 수도 있고, 어느 쪽이든 빌드되고 나면 동일하게 컴파일되고 실행되는 컴포넌트를 만들어내요.
각각 언제 사용할까
런타임 방식으로 구성하는 편이 여전히 가장 잘 맞는 경우는 페이지 구조 자체가 동적이거나 데이터 기반일 때예요 — 루프로 생성되는 행, 조건부 섹션, 런타임에만 알 수 있는 상태에 좌우되는 콘텐츠 — 그리고 IDE에 의존하지 않고 Delphi 7–13 전체에서 하나의 소스를 공유해야 할 때도 마찬가지예요. 디자인 서페이스가 가장 잘 맞는 경우는 대체로 정적인 페이지 구조를 시각적으로 배치하고, 만드는 동안 페이지의 형태를 직접 확인하고, 코드가 아니라 오브젝트 인스펙터에서 속성을 조정하고 싶을 때예요. 어느 쪽도 런타임 기능의 차이는 아니에요. 둘 중 하나를 고르는 것은 순전히 작성 시점의 취향 문제예요.
계속 발전 중
디자인 서페이스의 컴포넌트 팔레트는 계속 확장되고 있지만, 아직 몇 가지 부족한 부분이 남아 있어요. TsgcHTMLComponent_Panel의 카드 셸처럼 일부 컴포넌트 자체의 래퍼 마크업은 아직 이를 억제할 속성이 없어요. TsgcHTMLComponent_Form 필드는 손으로 작성한 마크업처럼 열 클래스나 span을 적용하지 못해요. 모든 속성이 모든 형제 컴포넌트에 존재하는 것도 아니에요 — 예를 들어 UseColorClass는 Panel에는 있지만 Login이나 StatCard에는 없어요. 그리고 TsgcHTMLComponent_Grid는 아직 정렬 가능한 열 헤더를 디자인 타임 속성으로 노출하지 않아요. 이 중 어느 것도 런타임 경로에는 영향을 주지 않으며, 팔레트는 릴리스를 거듭할수록 이런 격차를 계속 좁혀가고 있어요.
실제로 살펴보기
두 가지 방식을 나란히 비교해 보는 가장 확실한 방법은 sgcWebSockets에 포함된 Demos\60.HTML 폴더예요. 01.RunTime에는 원래의 코드 기반 데모가 들어 있고, 02.DesignTime에는 이 패턴을 시작한 ERP 데모와 함께 AdminCRUD, LiveMonitor, Portal, HTMX, Grid, Site, Components, Helpdesk, ShopAssistant, WebBroker, WebBrokerHTML까지 모든 데모가 디자인 서페이스를 이용해 폼 위에 완전히 다시 만들어져 있어요. 같은 데모를 두 폴더에서 비교해 보면, 서로 다른 두 작성 방식으로 만든 동일한 페이지를 확인할 수 있어요.
업그레이드
디자인 서페이스는 sgcWebSockets 2026.9.0의 sgcHTML 팩 일부로 제공되며, 기존 런타임 기반 페이지는 별도의 마이그레이션 없이 그대로 사용할 수 있어요. 무료 체험판을 받아 직접 사용해 보시고, 컴포넌트 허브에서 전체 컴포넌트 목록을 살펴보세요.
질문이나 피드백, 마이그레이션 관련 도움이 필요하신가요? 문의하기 — 코드를 직접 작성한 사람들에게서 답변을 받으실 수 있어요.
