Sub-views

A sub-view embeds another view (a child grid or form) inside a parent form/view — for example the line items under an order, or the stock movements under a product. Declare them in <SubConfig> and place them in the layout with <Sub>.

<SubConfig>
  <SubView Name="SaleItem" Label="Line Items" Icon="fa fa-list" Type="Table" RenderInView="Expanded" />
</SubConfig>

<SubView>: Name (the child view), Label, Icon, Color, Type (Table/Form), RenderInView (Disabled/Minimized/Expanded), NameColumn/LabelColumn, FormStyle, CustomJs. Reference it from the layout with <Sub Name="SaleItem" />.

Parent key

When a sub-view loads (grid expand or <Sub> in a form/view), the parent row’s columns are passed to the child as @Parent__{Column} parameters — notably @Parent__Id (the parent’s primary key). So the child’s <Sql> filters by, and its <InsertSql> assigns the FK from, @Parent__Id — not the child’s own column name:

<Sql …>   … WHERE si.IsDeleted = 0 AND (@Parent__Id IS NULL OR si.SaleId = @Parent__Id) </Sql>
<InsertSql>
  INSERT INTO Sales.SaleItems (SaleId, ProductId, …) VALUES (TRY_CAST(@Parent__Id AS INT), @ProductId, …);
</InsertSql>

Every parameter must be supplied

Every @parameter a query references must actually be supplied — there is no auto-binding. A sub-view always provides @Parent__Id; declared <Parameters> and pre-filters are supplied by their respective mechanisms. Referencing an unsupplied parameter raises “Must declare the scalar variable @X”.

Sub-views vs CartTable

For editable line items, prefer a <CartTable> with SubView="…" — the cart drives all three modes (editable in Create/Edit, the read-only sub-view in View), so you never need a separate <Sub>. Use a standalone <Sub> only for child grids that aren’t backed by a cart.

Worked examples: sample/Inventory/models/views/Products.view.xml (kitchen-sink), sample/Inventory/models/views/PurchaseOrders.view.xml (sub-views + cart), sample/Inventory/models/views/PurchaseOrderLines.view.xml (child grid).