DEV Community: Wuic Framework

Mobile-first auto-layout with zero config: how WUIC reflows enterprise tables on a phone

Wuic Framework — Fri, 31 Jul 2026 08:21:35 +0000

A complaint that comes up every time we demo WUIC to someone with a CRM or back-office app: "this is all very nice on a 27-inch monitor, but our reps live on iPads in the field, and your default list view is unreadable on a phone."

It used to be a fair complaint. The fix wasn't dramatic — a modest diff across two components, some SCSS, and one small service. But what we got out of it is zero per-screen configuration for mobile: every existing scaffolded route automatically gets a card-stack layout on phones and a vertically stacked edit form, and the dev doesn't write a single media query.

This post walks through how it's wired, and where it draws the line.

The default behavior

Open any list page on the public demo at 1920×1080 and you see a <p-table> from PrimeNG: dense, columnar, scrollable, with sort/filter/group headers. The classic enterprise table.

Now resize the window below 768px (or open it on a phone). The table layout disappears, and in its place is a vertical stack of cards — one per record. Each card shows the action buttons on top and a label/value row for every column that's visible in the list (the same mc_hide_in_list rules the desktop grid uses), with the same cell formatting: lookups resolve, uploads render thumbnails, colors render swatches.

No metadata change. No if (mobile) { ... } in your app code. Same route, same datasource, same metadata — the framework swaps the row template.

The edit form (<wuic-parametric-dialog>) reflows too: multi-column layouts collapse to a single column, fields go full-width, the tab list becomes horizontally scrollable, and the toolbar compresses.

Where the swap lives

There are two distinct mechanisms because they solve different problems.

List-grid: runtime row-template swap (TS)

The list-grid renders one PrimeNG <p-table> on both viewports — but the row template, which is compiled at runtime anyway (that's how per-route custom row templates work), is different on mobile:

// list-grid.component.ts (excerpt)
private getEffectiveGridRowTemplate(metaInfo: MetaInfo): string {
  // Mobile: the row template emits a single <td colspan> with a
  // card-style layout — same <p-table>, same JIT compile pipeline.
  if (this.deviceAwareness?.isMobile) {
    return this.buildMobileCardAsRowTemplate(metaInfo?.columnMetadata || []);
  }

  const customRowTemplate = String(metaInfo?.tableMetadata?.md_rowTemplate || '').trim();
  if (customRowTemplate) {
    return customRowTemplate;
  }
  // ... host override, then library default
}

On mobile the compiled row is a single <td colspan> containing the card markup; a wuic-list-grid-mobile CSS class plus a media query hide the <thead> and turn <tr>/<td> into display: block, freeing the DOM from table semantics. The template string is compiled into a real component class at runtime via Angular's ɵcompileComponent — the same pipeline that powers custom row templates on desktop.

The viewport detection is a singleton service:

@Injectable({ providedIn: 'root' })
export class DeviceAwarenessService {
  readonly isMobile$: Observable<boolean> =
    this.isMobileSubject.pipe(distinctUntilChanged());

  constructor() {
    const breakpointPx = this.resolveBreakpointPx(); // widgetDefinition, default 768
    this.mediaQueryList = window.matchMedia(`(max-width: ${breakpointPx}px)`);
    // ...listener pushes matches into the BehaviorSubject
  }
}

When the viewport crosses the breakpoint, the observable emits, the grid recompiles its row template, and the same <p-table> re-renders as cards. No reload, no double-fetch — the data is already in the component's records array.

Customizing the card: `mobileCardTemplate`

The default card is built for you — an action-button row on top, then one label/value row per visible column, reusing the exact same cell renderers as the desktop grid (a lookup link, an image thumbnail, a colour swatch all render the way they do in a table cell). For most back-office screens that's the whole job.

When you want a different card layout, the public WidgetDefinition API exposes a mobileCardTemplate hook — an Angular template string that replaces the card body. It's compiled at runtime through the same ɵcompileComponent pipeline as the row template and injected into the card cell, so inside it you have the grid's scope: rowData for the current record, the columns list, metaInfo, and the same helper pipes the default uses (formatGridViewValue, visibleFieldList, the cell-class helpers). One thing to know up front: it's set at the host level, so it applies to every grid in the app — it's a global card style, not a per-route override.

The full list of variables available in the template's scope is in the responsive-layout docs.

Edit-form: CSS-only reflow (SCSS)

The edit form is the opposite call. <wuic-parametric-dialog> already builds a flexbox row layout in plain HTML — there's no library DOM fighting us, and the mobile layout wants the same DOM, just stacked. So no template swap; a media query does it:

// parametric-dialog.component.scss
@media (max-width: 768px) {
  .row {
    display: flex;
    flex-direction: column;
    flex-wrap: nowrap;   // default .row wraps → phantom second column
    gap: 12px;
  }

  :host ::ng-deep .data-field-wrapper {
    width: 100% !important;
    max-width: none !important;
  }
  :host ::ng-deep .data-field-field {
    width: 100% !important;
  }
}

The !important is defensive: field widths come from mc_ui_size_width per-column (a designer-saved value rendered as inline styles) and the media query has to win on small screens. The same defensive rule lives in field-editor.component.scss so it applies whether the field is hosted directly or inside a wrapper.

Total mobile-specific code for the edit form: a few dozen lines of SCSS (stacking, tab-list scroll, compact toolbar). No TypeScript.

That covers the automatic reflow. When a screen needs a genuinely bespoke form — grouped panels, a custom header, fields laid out around an image — the edit dialog takes a full custom template too: set md_edit_template on the route and <wuic-parametric-dialog> renders your Angular form markup instead of the auto-generated field layout, compiled at runtime. Unlike the list's mobileCardTemplate (which is host-wide), this one is per-route, so each screen opts in independently; md_detail_template does the same for the read-only detail view. You own that markup — including how it reflows on a phone — so the automatic stacking above applies to the default layout, not to a template you hand-write.

Why the asymmetry? Because the list needs different DOM per viewport — cells versus cards — which is a template problem, while the form needs the same DOM in a different flow — which is a CSS problem. The right answer was different for each.

What we don't try to handle automatically

We've seen "responsive mode" sold as a magic checkbox, and we don't want to over-promise. Here's the explicit list of what stays manual:

Per-column priority on the card. The default card shows every column that's visible in the list. If you want "name + city + last_seen on the card, hide the rest", you hide columns via the existing mc_hide_in_list rules and condition system. We don't have a dedicated mobile_visible flag — adding a second flag for every responsive concern is how metadata schemas balloon.
Inline editing on mobile. Deliberately unsupported: tapping a card opens the edit form. Cell-by-cell editing on a 380px viewport is a UX trap we chose not to fall into.
Filter bar. On desktop it's an inline collapsible panel above the list. On mobile that's unusable (it ate most of the viewport in early prototypes) — so below the breakpoint the same content opens as a full-screen overlay with its own header and close button, and the list underneath stays intact. That behavior is hard-coded in the filter-bar component, not metadata; if you don't like it, you override the component.
Designer surfaces. Drag-and-drop designers (dashboard, report, workflow) are desktop tools; we don't attempt to make them mobile-friendly. Read-mode dashboards reflow fine.
Custom Angular components. If you wrote a custom widget (a colour picker, a map, a charting widget) and didn't think about mobile, it'll look bad on mobile. The framework doesn't know how to reflow third-party components — that's on you. DeviceAwarenessService.isMobile$ is public precisely so your components can make the same call the grid makes.

The breakpoint

The default is 768px, matching the Bootstrap-style convention (and the framework's own @media rules). Override per app at bootstrap — widgetDefinition is a static:

// main.ts (or an APP_INITIALIZER)
import { MetadataProviderService } from 'wuic-framework-lib';
import { environment } from './environments/environment';

MetadataProviderService.widgetDefinition.mobileBreakpointPx =
  environment.mobileBreakpointPx ?? 768;

The breakpoint is read once, at DeviceAwarenessService construction — changing it later means re-bootstrapping the app, which in practice nobody needs. The real use cases are static per app: "this app is tablet-first, raise it to 1024" or "this app runs on warehouse scanners, lower it to 600".

Performance corner

Two things worth mentioning, both consequences of the unification:

Virtualization comes for free. Card stacks can have hundreds of rows, and the first prototype rendered its separate card list entirely into the DOM — fine for 50 cards, smelly for 500. Since mobile now renders through the same <p-table>, the grid's virtual scrolling — gated by the same isListVirtualizationEnabled() switch as desktop — applies to the cards too. One flag, both viewports.

No churn on resize. isMobile$ goes through distinctUntilChanged, so the row template recompiles only on the actual boolean transition across the breakpoint, not on every resize tick.

When it's not enough

If you need a layout that's neither a desktop table nor a vertical card stack — say, a kanban board on phone, or a horizontally-paginated card carousel — the right answer is a different archetype, not a flag. kanban and carousel are archetypes in the framework's widget definition (alongside scheduler, map, tree and the rest), and each renders on both viewports with its own behavior.

Mobile auto-layout in WUIC handles the transactional archetypes (list + edit form), which is 80% of an enterprise back-office. The 20% — kanban, scheduler, map — has its own per-archetype responsive story.

Try it

The public demo runs in any browser at any width. Open DevTools, switch to a phone profile, navigate to any list — you'll see the card swap live. The credentials are on the sandbox landing page; login takes 2 seconds.

The full list of files involved (for the curious): device-awareness.service.ts, list-grid.component.{html,ts,scss}, filter-bar.component.{html,ts}, parametric-dialog.component.scss, field-editor.component.scss — plus the widgetDefinition.mobileBreakpointPx hook for app-side override.

The counterpart to auto-layout on the read side is the drag-and-drop dashboard designer — UI that writes JSON metadata, and how designer-saved boards survive runtime upgrades. And if you're wondering how those routes got scaffolded in the first place, start here.

Enterprise reports in three steps: SQL view drag-and-drop designer menu entry

Wuic Framework — Tue, 21 Jul 2026 12:37:53 +0000

The reporting story in most enterprise apps goes like this: build a stored procedure, expose it via a custom controller, write a TypeScript service to call it, embed a Stimulsoft (or Crystal, or Telerik) viewer, manually wire the parameters, manually handle the per-user filter, manually validate the permissions. Multiply by 40 reports. Each one is a tiny project.

The WUIC version: write a SQL view, scaffold it as a metadata route, lay the report out in the embedded designer (it saves into the route's folder for you), add a menu entry pointing at the route's report viewer. The framework picks it up. The same auth, per-user filtering, and column permissions that drive list pages apply to the report — for free, because it's the same route.

This post walks through the contract between the report, the route, and the viewer, and why naming discipline matters more here than anywhere else in the framework.

The example

Say you want a "Sales by Region" report that aggregates opportunities joined with accounts and groups by region. The SQL is straightforward:

CREATE VIEW vw_sales_by_region AS
SELECT
    a.region_code,
    a.region_name,
    COUNT(o.id)                  AS opportunity_count,
    SUM(o.amount)                AS total_amount,
    AVG(o.amount)                AS avg_deal_size,
    SUM(CASE WHEN o.stage = 'Won' THEN o.amount ELSE 0 END) AS won_amount
FROM dbo.opportunities o
INNER JOIN dbo.accounts a ON a.id = o.account_id
WHERE COALESCE(o.deleted, 0) = 0
GROUP BY a.region_code, a.region_name;

That's the data. Now the report.

Scaffold the view as a metadata route

The framework needs to know about the view in _metadati__tabelle so the runtime can resolve it, apply per-user column grants, and inject the user's filter context. Same tool as for tables: the built-in Scaffolding page. Its object dropdown lists tables, views (tagged [VISTA]) and stored procedures ([STORED]) — pick vw_sales_by_region, and this time leave "Create Menu" unticked, because we don't want the view to appear as its own list page; it's reachable through the report's own menu entry.

Scaffolding a view is the same click as scaffolding a table — the page detects it's a view and routes accordingly. It inserts a _metadati__tabelle row with mdroutename = 'vw_sales_by_region' and one _metadati__colonne row per column. (For automation it's the scaffolding.scaffoldView proxy method, sibling of scaffoldTable — but as with tables, the page is how you do it interactively.)

The columns are now metadata. The framework knows that total_amount is a decimal that should render with thousand separators, that region_name is a string used as the human-friendly group key, and that the view has 6 columns. None of that is in the report yet — it's in the metadata, and the report will read it.

Design the report against the route

You don't hand-write the .mrt XML. WUIC ships an embedded Stimulsoft report designer in the browser, at #/<route>/report-designer. When you open it for a scaffolded route, the backend seeds the report's data dictionary with that route's data source already wired up: the view's columns are sitting in the fields list, ready to drag onto the canvas. You lay out bands, drop fields, preview on real data — the designer writes the XML.

What it generates is worth understanding, because it's the contract the viewer relies on. The .mrt is XML, and the convention is that the SQL data source is named after the metadata route (spaces replaced by underscores):

<DataSources>
  <!-- StiSqlSource named after the route -->
  <vw_sales_by_region type="Stimulsoft.Report.Dictionary.StiSqlSource">
    <Name>vw_sales_by_region</Name>
    <Alias>vw_sales_by_region</Alias>
    <SqlCommand>SELECT 1 AS [__autogenerated], region_name, total_amount, ... FROM vw_sales_by_region</SqlCommand>
  </vw_sales_by_region>
</DataSources>

…and every binding expression in the report references {vw_sales_by_region.field_name} — again, filled in by the designer as you drag fields:

<Text>{vw_sales_by_region.region_name}</Text>
<Text>{vw_sales_by_region.total_amount}</Text>

The name match is a convention, not a hard wall: at render time the backend first looks up the data source by route name, then falls back to a case-insensitive match on name or alias, and finally — if the report has exactly one SQL source — uses that one. But rely on the convention; the fallbacks exist for legacy reports.

Note the 1 AS [__autogenerated] sentinel column. That's how the engine tells auto-generated queries apart from hand-written ones. If the sentinel is present (or the command is empty), the backend regenerates the query on every render from the current metadata and the current user — visible columns, lookup joins, user-scoped filters. If you've replaced the SQL with your own hand-written query, the sentinel is gone and the engine leaves your SQL alone.

You don't write a backend endpoint for the report. You don't write a TypeScript service. The report is a .mrt file in a folder, and the framework finds it, rebinds its connection to the route's database, and executes it with the caller's identity.

Where the .mrt goes on disk

Convention — in the project root of the app:

<App>/Reports/<route>/<filename>.mrt

For our example:

CrmApp/Reports/vw_sales_by_region/vw_sales_by_region.mrt

The <filename> is arbitrary — if you omit reportName the viewer defaults to Report.mrt. What matters is the folder is named after the route, because the viewer constructs the file path from it:

#/vw_sales_by_region/report-viewer?reportName=vw_sales_by_region.mrt

Drop that URL into a menu entry in _metadati__menu and it shows up in the navigation. Click it, the viewer opens, the report renders with live data.

Multiple .mrt files per route are supported — say summary.mrt and detailed.mrt for the same view, with the menu offering both as options. Each menu entry passes its own reportName=.

One backend prerequisite: AppSettings.reportQueryTimeout must exist in appsettings.json (e.g. "120"). The viewer parses it to set the SQL command timeout on every data source, and a missing value is a 500 at render time, not a graceful default.

What's reused from the rest of the framework

This is where the metadata-driven story pays off:

Auth. The viewer endpoints run the same authentication the rest of the API uses. No separate report login. If the .mrt declares a user_id variable, it's set to the authenticated user at render — usable directly in hand-written SQL.
Filter context. For auto-generated queries, the backend rebuilds the SQL per render via the same query builder the list page uses, so user-scoped filters (e.g. country_code IN (user's territory)) apply to the report automatically. Filters passed on the URL flow into the same rebuild.
Per-column grants. Column visibility is resolved per user and role — the same grant rules (mc_grant_by_default, role/company grants) the list page applies. A column the user isn't granted never enters the generated query, so it never reaches Stimulsoft at all. Caveat: this applies to the auto-generated query. Hand-written SQL in the .mrt is preserved verbatim, which means it also bypasses the column gate — you own that trade-off.
i18n. The designer seeds field aliases from _metadati__colonne.mc_display_string_in_view, and the viewer calls Stimulsoft's report localization with the app's current language at render time. Labels follow the language the user is already using in the rest of the app.
Caching. Stimulsoft's report and image cache are wired per route under Reports/cache/<route>; the metadata snapshot is already in memory. On the demo dataset a report renders in about a second.

What you'd have rolled by hand in a custom controller — auth, filter context, per-column gate, i18n, caching — is the framework's default for every route.

A note on the dictionary

One detail worth calling out about that designer: the pre-populated dictionary includes the fields of every lookup the route declares, not just the view's own columns — so a foreign-key column shows up with its resolved display fields, ready to drop into the layout. If you add or remove metadata columns later, reopen the designer to regenerate the dictionary.

Saving from the designer publishes it: the .mrt lands in the route's folder automatically. There's no separate "register report" step — the folder structure IS the registration.

Naming discipline (a real warning)

We mentioned in the scaffolding post that naming discipline is the hardest thing about a metadata-driven framework, and reports are where it hurts the most.

Specifically:

View names are stable contracts. A .mrt file references vw_sales_by_region.total_amount. Rename the view (or the column) and every report referencing it breaks. The framework can't auto-rewrite the .mrt for you; from its perspective the file is opaque XML.
Filename is part of the URL. A menu entry at ?reportName=sales-summary.mrt is bound to that filename. Rename sales-summary.mrt to summary.mrt and the menu entry breaks until you update it.

What the framework does to make these failures visible instead of mysterious:

A missing or misnamed report file returns a typed error envelope (errors.report.not_found, HTTP 404) carrying the route, the report name, and the path it looked at — localized in the UI instead of a raw stacktrace.
The client runs a lightweight preflight before mounting the Stimulsoft viewer, because the viewer itself crashes ungracefully on any non-200. If the file isn't there, you get a clean localized dialog and the viewer never mounts.
The __autogenerated sentinel keeps the engine from clobbering hand-written SQL on re-render — the most common way a "working yesterday" report used to die.

What the report engine does NOT do

In the same spirit as our other posts on this framework — here's what's deliberately out:

Cross-route reports as a first-class concept. A report is bound to one metadata route, but that doesn't mean it can only see one table. The auto-generated query already joins every lookup the route declares: if opportunities has account_id as a lookup on accounts, the account's display fields show up as draggable fields in the designer dictionary. For joins the metadata doesn't capture, you edit the SQL by hand in the designer — the sentinel logic then preserves your query. A SQL view (like this post's example) remains the cleanest option for heavy aggregations.
Stored procedures as report sources. Reports run against routes backed by tables and views, executing SQL from the .mrt. There is no stored-procedure scaffolding for reports. For the classic "print one invoice" case you don't need one anyway: declare a report variable flagged as SQL parameter, use it as @invoice_id in the query, and pass the value on the URL (...&parameters=invoice_id||eq||42). The framework fills the variable; the query stays a query.
Designer customization at runtime. The end-user can't edit the .mrt in the browser. Editing is in the designer (embedded or standalone), and saves go to the same .mrt file on disk. If you need user-customizable layouts, the right answer is the dashboard designer (which writes JSON metadata, not .mrt), not the report engine.

Try it

The public demo ships seeded reports built on the tutorial data — open one from the menu and it renders in the embedded viewer with print, export-to-PDF, and export-to-Excel out of the box.

To build your own you need write access to the Reports/ folder, so on the hosted demo this part is read-only for visitors — but the workflow is exactly the same on a self-hosted install: scaffold a view, save a .mrt from the embedded designer, add the menu entry.

If reporting is the "output" half of the metadata story, the input half is just as automated — see how the same routes behave on a phone with zero configuration, or how the workflow engine drives state transitions over the same metadata.

From SQL table to working CRUD form in 30 seconds: a metadata-driven scaffolding approach

Wuic Framework — Wed, 15 Jul 2026 15:33:02 +0000

The cleanest demo of WUIC is also the boring one: write a SQL CREATE TABLE, click one button, refresh the browser. There's a working list page, an edit form, validation rules, lookup widgets, sortable columns, mobile responsiveness — and you wrote no Angular. No controller. No service. No DTOs.

This post walks through what's actually happening when you do that, and what it's not doing (because over-promising is how low-code platforms lose trust).

The 30 seconds, end-to-end

Suppose you want to add a "vendors" entity to your CRM. You'd typically do this:

CREATE TABLE vendors (
    id              INT IDENTITY(1,1) PRIMARY KEY,
    name            NVARCHAR(200) NOT NULL,
    vat_number      NVARCHAR(20)  NOT NULL UNIQUE,
    country_code    CHAR(2)       NOT NULL,
    contact_email   NVARCHAR(255) NULL,
    contact_phone   NVARCHAR(50)  NULL,
    notes           NVARCHAR(MAX) NULL,
    created_at      DATETIME2     NOT NULL DEFAULT SYSUTCDATETIME(),
    is_active       BIT           NOT NULL DEFAULT 1
);

Then open the built-in Scaffolding page (it ships as an admin menu entry — no code, no external tool). Pick the connection, the database, and the vendors table from the dropdowns, tick Create Menu, and hit Scaffold Table:

The same page has a few neighbours: Scaffold DB does every table in a schema at once, Scaffold Columns re-reads a table you've already scaffolded and adds the columns you added since (without clobbering your manual tweaks), and Scaffold OData exposes the route as an OData endpoint. It's all driven by the same handler underneath — scriptable via the scaffolding.scaffoldTable proxy method if you'd rather automate it, but the page is how you do it day-to-day.

Refresh the app. There's a new menu entry "Vendors" with:

A list page at /vendors/list showing all rows with sort, filter, group, paginate.
An edit form at /vendors/edit/:id with one field per column, validation rules from the schema.
An API at /api/Meta/AsmxProxy/vendors.crudRead etc., ready to call.
A mobile layout that collapses the table into a card stack below 768px.

That's the headline. Now the substance.

What the scaffolder actually inspects

The endpoint handler reads three things from the database:

1. INFORMATION_SCHEMA.COLUMNS. Column name, data type, nullable, default value, max length. This drives the field widget choice (text vs. textarea vs. number vs. date vs. checkbox), the validation (required from IS_NULLABLE, max length from the type), and the formatting (decimal places, date format).

2. INFORMATION_SCHEMA.KEY_COLUMN_USAGE + REFERENTIAL_CONSTRAINTS. Foreign keys turn into lookup widgets automatically. If vendors.country_code references countries.code, the form shows a dropdown populated from the countries route.

3. Identity / unique constraints. id columns get hidden in the edit form. Unique columns get a "value already taken" validation message wired to the API's duplicate-key error response.

That's it. No annotations, no decorators, no [Required] attributes scattered across DTOs. The information already lives in the schema; we just read it.

What ends up in metadata

The scaffolder inserts two rows into the WUIC metadata tables:

_metadati__tabelle: { md_id: 142, md_nome_tabella: 'vendors', mdroutename: 'vendors' }

_metadati__colonne (one row per column):
  { mc_id: 1781, md_id: 142, mc_nome_colonna: 'name',          mc_ui_column_type: 'string',  mc_validation_required: 1, ... }
  { mc_id: 1782, md_id: 142, mc_nome_colonna: 'vat_number',    mc_ui_column_type: 'string',  mc_validation_required: 1, ... }
  { mc_id: 1783, md_id: 142, mc_nome_colonna: 'country_code',  mc_ui_column_type: 'lookupByID', mc_ui_lookup_entity_name: 'countries', ... }
  …

Once these rows exist, the runtime takes over. There is no codegen step, no file written to disk, no Angular ng generate. The Angular components (<wuic-list-grid>, <wuic-parametric-dialog>, <wuic-field-editor>) read the metadata at runtime and self-configure.

This is the core trick: there is one set of generic UI components in the framework, and they specialise themselves based on metadata. We don't generate code per entity. We generate metadata, and the generic code reads it.

The 80/20

The 80% of the form is right out of the box. The 20% you tweak by hand falls into a few buckets:

Field labels. The scaffolder uses the SQL column name (vat_number → "Vat number"). For customer-facing UI you want "VAT number" or "P.IVA". You edit one row in _metadati__colonne (mc_display_string_in_view) and reload the metadata. Took 10 seconds.
Field grouping. By default every column goes in one section. To split "Identity" / "Contact" / "Notes" tabs you set mc_edit_associated_tab per column. Two SQL UPDATEs.
Custom validation. Things SQL can't express — "contact_email must end in @customer's allowed domain" — go into mc_validation_callback, a JS one-liner stored in metadata. Runs both client-side and server-side.
Custom widget. A specific column needs a custom Angular component (e.g. a colour picker). You write the component once, register it as a custom widget, and any column with mc_ui_column_type: 'colorPicker' gets it. Wrote it for one entity, reusable everywhere after.

Each tweak is a SQL UPDATE away from being live. No rebuild, no Angular recompile.

Same metadata, different archetype — the route can render as a kanban board or a spreadsheet without re-scaffolding:

What scaffolding does not do

We've seen low-code platforms over-promise here. Here's what scaffolding deliberately won't try:

Business logic. Workflow transitions, conditional approvals, computed fields — these are not in the schema, so the scaffolder doesn't invent them. You configure them afterwards (workflow engine has its own metadata; computed fields have callbacks).
Layout decisions. The scaffolder lays out fields in column order. For complex forms that's wrong; you edit a few mc_ordine values and mc_edit_associated_tab to fix it.
Permissions. Brand-new tables get default "all admin" permissions. Granular per-role / per-row rules live in the _mtdt__tnt__trzzzioni__* tables and have to be configured deliberately.
Cascade deletes & soft-delete columns. If your schema has a deleted flag, the scaffolder doesn't auto-filter it; we make this explicit per-route to avoid surprises (one of our oldest bugs was "why are deleted records still showing in this one screen").

How it scales

The team that uses this most internally has scaffolded ~140 routes. Each one is a SQL DDL change + an UPDATE _metadati__* for tweaks. The runtime metadata cache is a single in-memory snapshot, refreshed via MetaService.invalidateMetadataRuntime when a row changes. The whole thing is fast: a 100-column table with three FK lookups scaffolds in around 600ms server-side.

The interesting bottleneck isn't performance — it's naming discipline. When the metadata table has 140 routes and 1,800 columns, "what does mc_extra_2 mean?" becomes an actual question. We've ended up with an internal style guide for column naming. Boring, important.

When NOT to scaffold

A short list, because honest documentation matters:

Tables that already have a heavily customised hand-written UI. Re-scaffolding overwrites your tweaks. Use the dedicated update endpoint that preserves manual edits, not the full scaffold.
Tables you don't actually want users to see. Auto-generating a UI for _audit_log is a footgun. Scaffolding is opt-in per table; we keep it that way.
Polymorphic / EAV schemas. If your "products" table has a JSON attributes column with arbitrary keys, scaffolding will give you a textarea for that column. Fine, but obviously not the UX you'd hand-craft.

Try it

The Scaffolding page runs on the public demo. The demo data is reset every 24 hours, so you can CREATE TABLE foo (id int identity, name nvarchar(100)), scaffold it, see the auto-generated CRUD, then leave — by tomorrow the schema is clean again.

If you want to read how it works under the hood: the scaffolder entry point is scaffolding.scaffoldTable (one gateway per DBMS — SQL Server, MySQL, PostgreSQL, Oracle — because INFORMATION_SCHEMA is only mostly portable). The in-product codebase chatbot (covered here) can find the exact files for you faster than I can paste links.

If this sounded interesting, the follow-ups are already out: how the mobile auto-layout turns a desktop table into a card stack with zero per-screen config, and how the workflow engine runs multi-step business processes from a graph metadata table. Or skip the reading and try the live demo — the schema resets every night at 4:00, so you can scaffold anything you like.

The chatbot's toolbox: the actions an LLM can apply to your app

Wuic Framework — Thu, 18 Jun 2026 07:31:13 +0000

A chatbot that only answers questions is a search box with manners. Ours does more: it can propose concrete changes to the app you're looking at. You describe what you want in plain language, the model picks the right tool, and you get a proposal — a chip with an Apply button, the generated code, the target route, and the model's rationale, all visible before anything happens.

If you know MCP (the Model Context Protocol), the mental model is the same: hand the model a catalogue of typed tools and let it call them. We define the tools inline against the Anthropic tool-use API rather than behind an MCP server, but the shape is identical — a name, a description that tells the model when to use it, and a typed argument list. The model never touches a database; it produces a structured intent and the framework owns the execution.

One rule sits above all of them: nothing is applied without a click. The model proposes, you dispose.

▶ Media — overview clip: asking the chatbot for an action and the resulting "Apply" chip appearing under the answer.

Below is the catalogue, one tool at a time, each with the kind of prompt that triggers it.

Grid actions

`propose_toolbar_action`

Adds a custom button to a list grid's toolbar, operating on the current selection, with a generated JavaScript callback.

You:  "on the orders grid add a button that exports the selected rows to CSV"

Bot:  toolbar action  ▸ Apply
      route:    orders
      callback: const rows = datasource.getSelectedRows();
                const csv = toCsv(rows); download('orders.csv', csv);

`propose_row_action`

Adds a button to a single row (in the row's action dropdown), with a callback that receives that record.

You:  "put an Approve button on each row of the requests grid"

Bot:  row action  ▸ Apply
      route:    requests
      callback: await fetch('/api/requests/approve', {... id ...});
                await datasource.fetchData();

Conditional styling

`propose_table_style`

Applies a CSS class to a whole row when a JS condition is true (a row-level highlight).

You:  "highlight in red the rows whose due date is in the past"

Bot:  table style  ▸ Apply
      class:     row-danger
      condition: new Date(record.due_date) < new Date()

`propose_column_style`

Same idea, scoped to a single cell instead of the whole row.

You:  "give the status cell a green background when it's 'OK'"

Bot:  column style  ▸ Apply
      column:    status
      class:     cell-success
      condition: record.status === 'OK'

Cell rendering and form titles

`propose_display_formula`

Replaces a column's rendered value in the list with a custom HTML/Angular template — a badge, an icon, a coloured number.

You:  "show priority as a coloured badge: green/yellow/red"

Bot:  display formula  ▸ Apply
      column:  priority
      template: <span class="badge" [class.high]="...">{{ priority }}</span>

▶ Media — screenshot: the priority column rendered as coloured badges.

`propose_form_title_formula`

Computes the edit-form's title dynamically from the record being edited.

You:  "the edit form title should read 'Customer {company_name}'"

Bot:  form title formula  ▸ Apply
      route:  customers
      formula: `Customer ${record.company_name.value}`

▶ Media — clip: opening a record and seeing the dynamic title in the dialog header.

Form callbacks

`propose_default_value_callback`

Generates the callback that prefills a field when a new record is opened.

You:  "default created_date to today on new records"

Bot:  default value  ▸ Apply
      column:   created_date
      callback: record[field.mc_nome_colonna] = new Date().toISOString().slice(0,10);

▶ Media — screenshot: the insert form opening with the date prefilled.

`propose_custom_validation`

Generates a validation that blocks the save when a rule — possibly cross-field — isn't met, with a message.

You:  "validate that population can't be negative, block the save with a message"

Bot:  custom validation  ▸ Apply
      column:   population
      callback: if (record[field.mc_nome_colonna].value < 0) {
                  vr.message = 'Population cannot be negative'; return false;
                } return true;

▶ Media — clip: typing a negative value, hitting Save, and the validation blocking it.

`propose_selection_changed`

Hooks the change of a lookup/select field to recompute or prefill other fields.

You:  "when the customer lookup changes, copy its VAT number into the record"

Bot:  selection changed  ▸ Apply
      column:   customer
      callback: record.vat_number.next(record.customer__lookup_obj.value?.vat ?? '');

▶ Media — clip: picking a customer and watching the VAT field auto-fill.

`propose_lifecycle_callback`

Hooks a record lifecycle event — before/after save, after load — for a side effect.

You:  "before save, uppercase the city name"

Bot:  lifecycle callback  ▸ Apply
      event:    before_save
      callback: record.CityName.next(record.CityName.value.toUpperCase());

▶ Media — clip: saving a lowercase name and seeing it stored uppercase.

Metadata

`propose_simple_metadata_update`

Patches a simple metadata field — page size, a caption, hide-in-list/edit, a basic flag — without opening the metadata editor.

You:  "set the cities grid page size to 50"

Bot:  metadata update  ▸ Apply
      route:  cities
      field:  page size → 50

▶ Media — screenshot: the grid paging at 50 rows after Apply.

`propose_metadata_column_create`

Creates a new column on a route — including a computed (non-physical) one.

You:  "add a computed column total_chars = LEN(city_name)"

Bot:  create column  ▸ Apply
      route:    cities
      column:   total_chars (number, computed)
      formula:  LEN([Application].[Cities].[CityName])

▶ Media — screenshot: the new computed column showing in the grid.

SQL (super-admin)

`propose_sql_metadata_field`

Writes a raw SQL fragment into a metadata field — a custom JOIN, a computed expression, a custom SELECT clause — concatenated at runtime into the auto-generated queries. The model generates the fragment in the active provider's dialect (MSSQL / MySQL / PostgreSQL / Oracle quoting and syntax).

You:  "on the orders total column, compute price × quantity"

Bot:  SQL metadata field  ▸ Apply   (super-admin)
      target:  orders.total (computed expression)
      sql:     [price] * [quantity]

This is the only tool gated harder than a click: it requires super-admin privileges server-side and writes an audit log row on every application.

▶ Media — screenshot: the computed total column + the audit log entry.

Designer canvas

`propose_designer_inject`

The one tool that does not write metadata. On the dashboard designer page it injects or edits components on the canvas — the same in-memory tree the drag-and-drop UI manipulates. Nothing persists until you click "Save dashboard", and the designer's undo/redo covers the model's edits exactly like a human's.

You:  "add a grid bound to cities"   (on the designer page)

Bot:  designer inject  ▸ Apply
      injects: DATASOURCE + DATAREPEATER, bound and configured for route 'cities'

It knows the full catalogue of canvas tools and their editable properties, and it fuzzy-matches sloppy route names ("provincie" → stateprovinces) before committing to an argument.

Before it acts: asking for the schema

Every tool above needs real names — the actual column name on the route, the SQL schema and table, the join alias behind a lookup. Early versions handed all of that to the model upfront: the page context was a full dump of every column on the current grid. It bloated every request, action or not.

So we flipped it. The page context is now minimal — just the route you're on, e.g. cities/list. When a prompt needs schema the model doesn't already have, it calls one more tool first:

request_metadata_detail — a non-chip, behind-the-scenes tool. {detail: 'columns', route} returns the real column list and the SQL identity (schema, table, the full qualifier to use in a formula); {detail: 'lookup_columns', route, column} returns a lookup's join alias and its related columns. The framework resolves it — the model still never touches the database — hands the result back, and then the model emits the propose_* with names it looked up instead of names it guessed.

You:  "show the province lookup as 'id - name'"

Bot:  (calls request_metadata_detail → learns the join alias
       is StateProvinceID_stateprovinces) then:
      SQL metadata field  ▸ Apply
      sql:  CAST([StateProvinceID_stateprovinces].[StateProvinceID] AS VARCHAR(10))
            + ' - ' + [StateProvinceID_stateprovinces].[StateProvinceName]

It's the same trust property as everywhere else, one level deeper: the model can't reference a column or an alias that doesn't exist, because it asks before it acts — and the prompt stays lean, fetching only what the question needs.

The quiet tools

Three tools never produce a chip — they shape the conversation instead:

remember_fact / forget_fact — the model pins high-priority facts it shouldn't lose ("this project uses snake_case columns"). They survive summarisation.
suggest_followups — the clickable chips under each answer that propose the next question.

▶ Media — screenshot: a memory fact pinned in the header + follow-up chips under an answer.

Why a fixed toolbox

A typed catalogue over a metadata-driven framework is a good fit precisely because the framework already has a small, safe, well-defined surface of "things you can configure". The model never writes arbitrary code that runs unsandboxed; it fills in the blanks of operations the framework was already designed to perform — and you approve each one with your eyes on the preview.

The chatbot, and this whole action layer, ships with every WUIC install and runs on the public demo. Open it on a list grid and ask it to colour the overdue rows red. Read the chip. Then click Apply. For how the engine behind it is built and served, see the architecture post.

The architecture of an in-product RAG chatbot: from your prompt to the answer

Wuic Framework — Thu, 11 Jun 2026 14:09:09 +0000

The pitch we kept hearing was: "just embed ChatGPT into your product". A week of work, an OpenAI key, you're done. That works for a marketing copilot or a generic FAQ bot. It does not work for the kind of question our users actually ask:

Where in the codebase is the multi-tenant authorization handled?
What does the "savemetadata" endpoint do under the hood?
How is the demo data restored at 04:00 UTC?

For these questions, the answer that matters is the file path. A confident-sounding paragraph that hallucinates MetaService.cs:123 when the file is actually MetaController.cs:847 is worse than no answer — it makes the user lose trust faster than a 404 would.

So we built a real RAG. This post is the architecture: it follows one prompt from the moment you hit send all the way to the cited answer, and explains the choices behind each step.

in action — natural-language question about the codebase, streamed answer with clickable file-path citations">

What "in-product RAG" means here

The chatbot lives inside the framework as <wuic-rag-chatbot>, an Angular standalone component. A user opens any WUIC-built application (or our docs), clicks the floating button bottom-right, asks a natural-language question. The answer comes back with citations: real file paths in the codebase that the user can click to open the matching chunk. The component owns nothing but the conversation — the floating button, the streamed answer, the session list. Everything stateful lives server-side.

The journey of a single prompt

Here is what actually happens between hit send and read answer. Four boxes, in order:

<wuic-rag-chatbot>   →   RagController   →   RAG engine   →   Claude
   (Angular)             (.NET)              (retrieval)       (synthesis)

1 — The component posts the question. <wuic-rag-chatbot> sends POST /api/Rag/Ask with three things: the question, the current session id, and the route context — which page you're on, e.g. cities/list. That context is deliberately minimal: just the current route, not a dump of every column. It's enough for the bot to know which grid you mean when you say "add a validation to this column"; the real column names it needs to act are fetched separately, on demand (see A leaner prompt: schema on demand, below).

2 — The controller authenticates and persists. RagController checks the session cookie, loads or creates the chat session, and writes your message to _rag_chat_messages before doing anything expensive. If the conversation is getting long, this is also where a background summary may already have been folded into the system prompt (more on that below).

3 — The engine retrieves. The query goes into the retrieval pipeline, which is the heart of the thing. In order:

Tokenize the query with an XLM-RoBERTa SentencePiece tokenizer.
Detect language; if it's Italian, translate to English first (cached) — the retriever was tuned on English.
Embed the query with bge-m3 into a dense vector, and compute its BM25 sparse scores in parallel.
Fuse the dense and sparse rankings with reciprocal-rank fusion → a top-40 candidate set.
Blend and rerank: a min-max blend with an adaptive alpha, then a cross-encoder rerank (the fine-tuned one — see below) over those 40, with small boosts for source type and title match → the top 8.

4 — The engine assembles the prompt. The top-8 chunks become the context, joined by the route context, any pinned memory facts, and the rolling conversation summary. That bundle, plus a short system prompt and a catalogue of tools, is what goes to the model.

5 — Claude answers — or acts. Most of the time the model writes prose with the file paths preserved as citations, and it streams back token by token. But the same call also exposes a toolbox: if your question was actually a request to change something, the model emits a tool call instead of prose, and you get an "Apply" chip rather than a paragraph. (That action layer is a post of its own — here it's enough to know the retrieval-and-synthesis path and the tool path are the same request, branching only at the model's choice.)

6 — The controller closes the loop. The assistant message is persisted, the context-window cue in the header is updated from the tokens the API actually reported, and — if history crossed a threshold — an auto-compact is queued so the next turn starts leaner.

The rest of this post zooms into the choices behind the interesting steps.

A leaner prompt: schema on demand

The bot needs real names to act — the actual column names of a grid, the SQL schema and table, the join alias behind a lookup. The first version shipped all of that inside the route context: every request carried a full column dump whether the prompt needed it or not. It saturated the window and spent tokens on every turn, prompt or not.

So we inverted it. The route context is now just the current route. When the model needs schema it doesn't have, it asks for it: a non-chip tool, request_metadata_detail, that the engine resolves against the metadata (the model never touches the database) and feeds back as a tool result before the model continues. The retrieval-and-synthesis loop above gains one optional inner hop — ask for the columns, then act — and the prompt only ever carries what the question actually needs. The same mechanism extends to any metadata dimension — lookups, related routes, enum values — without re-bloating the context. The action layer that consumes those names is a post of its own.

The shape of the index

We chunk the entire codebase by symbol — one chunk per class, one per top-level method — plus one chunk per documentation page section. Around 8,800 source chunks and several thousand doc chunks. Each chunk knows its file path, its symbol type and name, a dense embedding from BAAI/bge-m3, and its BM25 sparse vector.

The choice of bge-m3 was deliberate. We tried OpenAI's text-embedding-3-large and bge-m3 (heavier, public weights, no API call needed). For our corpus — code with a lot of camelCase identifiers and an Italian/English mix — bge-m3 won by ~6 points on hit@8. More importantly the weights are local, so the retrieval has zero API surface to a third party. A user's question never leaves the box for retrieval; only the synthesis step talks to Claude.

Hybrid retrieval, not pure vector

The first version was pure cosine similarity over the embeddings. It worked for "concept" questions ("how does multi-tenant authorization work?") but missed precise lookups ("AsmxProxy/MetaService.invalidateMetadataRuntime") — the embedding for a verbatim symbol name was less useful than a literal text match.

Adding BM25 in parallel and fusing with reciprocal rank fixed it, and the failure mode is the interesting part: BM25 catches the queries that look like grep, vector catches the queries that look like sentences. They cover different mistakes. That's the architectural reason both are in the pipeline rather than one or the other.

Fine-tuning the cross-encoder

The fusion step returns top-40 candidates. The next step is a cross-encoder reranker — a BAAI/bge-reranker-v2-m3 that scores each (query, chunk) pair end-to-end. Slower than the dual-encoder retrieval (≈300 ms vs 30 ms for top-40), much more accurate.

The base reranker was good. Fine-tuning it with LoRA was much better, and this is where most of our quality gains came from.

We mined hard negatives — chunks the dual-encoder returned but a human marked as wrong — and trained a small adapter (rank=16, alpha=32, ~3.4M trainable parameters out of a 568M base). Two iterations:

First adapter, trained on 11k mined examples, blend 0.85 → hit@8 went from 0.61 (base) to 0.87 on our 603-case eval set. Dramatic.
Second adapter, retrained on 8k examples remined against the rebuilt index → held the in-distribution number (0.81) but jumped on the holdout test (0.74 → 0.78). Less Goodhart, better generalization. That's the one in production.

                                   hit@8  MRR
base CE, top_n=20, blend=0.65      0.74   0.58
LoRA v2 (11k-mined), top_n=40      0.87   0.76
LoRA v2 (8k-mined, current)        0.81   0.66   ← production default

The architectural decision here was where to spend the fine-tuning budget. We tried fine-tuning the bge-m3 retriever itself: marginal gains, big training-infra footprint. An adapter on the reranker, with the dual-encoder left frozen, gives most of the win for a fraction of the cost — and the adapter is 3.4M parameters you can swap without touching the index.

Translating Italian queries

Half our users type in Italian. bge-m3 is multilingual, but the cross-encoder was trained mostly on English. Translating Italian queries to English before the reranker bought ~2 points on hit@8. We use NLLB-200-distilled-600M locally (no API call), with a translation cache that persists across runs — ~80 ms cold-start once, ~12 ms per query after.

Why Claude for synthesis

Once retrieval has the top 8 chunks, they go to Claude with the question. Two reasons specific to our use case drove that choice over GPT-4o:

Long context without the latency cliff. Our top-8 can hit 4–6k tokens combined; Claude handles that without the slowdown we measured on the same payload elsewhere.
Better at not answering. Our biggest failure mode is the model confidently inventing an answer when retrieval came back empty. With the same "if you don't know, say so" instruction, Claude said so markedly more often when retrieval was bad. We'll take that.

Serving it natively on .NET

The retrieval models are PyTorch-shaped, so the obvious way to serve them is Python. Our v1 was exactly that: a FastAPI process, rag_server.py, that the .NET controller proxied to. It worked, but it meant a second runtime on every customer box — a venv, an NSSM-wrapped service on Windows or a systemd unit on Linux — and every "the chatbot returns 502" support thread ended at the same place: the Python service had died or drifted. Retrieval quality was never the problem; the operational surface was.

So we ported the whole inference path to native .NET on ONNX Runtime. Training stays in Python — you don't retrain a cross-encoder in C#. Inference moved:

Every model exports cleanly to ONNX; Microsoft.ML.OnnxRuntime.Gpu runs the graphs in-process with a CUDA provider and a transparent CPU fallback.
Microsoft.ML.Tokenizers gives the same XLM-RoBERTa tokenizer. We gated it against the Python tokenizer on 200 queries: 198 identical, 2 off by a one-token tie-break worth <0.04 of a logit.
The 8-stage pipeline above was re-implemented stage for stage and diffed against the Python twin: cosine 1.0 on embeddings, 99.4% ranking agreement.

The architectural trick that keeps this clean: the engine lives in its own assembly with zero compile-time reference from the main app. Only when the feature is enabled does a custom AssemblyLoadContext load WuicRagEngine.dll and its native ONNX dependencies, invoked across a deliberately dumb seam — JSON in, JSON out, by reflection. A build that never touches the chatbot never links a single native binary. The DLL ships next to the app; the ~2.3 GB of weights and index download on first launch into a local folder.

The payoff isn't speed — GPU numbers are within noise of the Python build. It's the deploy story: "install .NET, unzip, run" instead of a Python install guide that reads like a support ticket.

What didn't work

A short list of approaches we dropped, so the next person can save the time:

Vector-only retrieval, no BM25. Catastrophic on <symbol> lookups.
Pure cross-encoder on top-100 candidates. 8× slower than top-40, only +1pp hit@8.
Re-ranking with GPT-4 directly. Worked, but 2.5 s/query and 30× the cost of the LoRA reranker.
Fine-tuning the bge-m3 retriever instead of the cross-encoder. Marginal gains, big training footprint. Adapter on the reranker, leave the dual-encoder alone.
Including diff history as context. The bot learned to answer "what changed last week" by hallucinating diffs. Pulled it.

What's the chatbot actually for?

Answering questions is half of it. The half we use more is the chatbot doing things on the app you're looking at — proposing a button on a grid, a row colour rule, a computed column, a metadata patch — through a typed catalogue of tools the model can call. Every proposal is a chip with an Apply button, the generated code, and the target route, all visible before anything runs.

The headline example: the dashboard designer. With the designer open, ask:

"add a grid bound to provincie"

The model fuzzy-matches "provincie" to the real stateprovinces route, generates the DATASOURCE + DATAREPEATER components configured for it, and drops them on the canvas as a single proposal. Nothing persists until you click "Save dashboard"; designer undo/redo covers the model's edits exactly like a human's. The bot just saved you the drag, the binding panel, and the route lookup.

The full toolbox — toolbar actions, row actions, conditional styling, custom validations, lifecycle callbacks, metadata patches, even raw SQL fragments in the active dialect — is the subject of the follow-up post.

Try it

The chatbot is part of every WUIC install and runs on our public demo — open it, click the floating button, ask anything. The retrieval index is the WUIC framework itself, so "how does the dashboard designer save state?" returns a real answer. And when you want it to do something rather than explain it, that's the tool layer.

The dashboard designer: drag-and-drop that writes JSON metadata, not Angular code

Wuic Framework — Wed, 03 Jun 2026 07:55:31 +0000

A common pattern in low-code platforms: the visual designer is a beautiful UI, but it compiles your dashboard into something opaque — a binary export, a per-tenant Angular bundle, an XML the runtime can't pretty-print. Whatever the format, you can't open it in cat, you can't grep it, and a "small fix" requires re-opening the designer.

WUIC ships a visual designer that runs in the browser and writes plain JSON. One row in dom_board, one JSON column called boardcontent. Plus optional CSS attached per board in dom_board_sheet. Pretty-printable. Diff-able. The runtime reads the JSON at load time, pulls in the linked stylesheets, and builds the component tree with no per-tenant build.

This is the trade-off we made and the parts of it I'd defend.

The designer

The designer is an Angular component (<wuic-designer>) that the framework opens when you click "Edit" on any dashboard route. It has three panels:

Palette on the left. A scrollable list of every component the runtime knows how to render — layout primitives (TABLE, TR, TD, DIV, SPAN), data primitives (DATASOURCE, DATAREPEATER, CHART, MAP, KANBAN, SCHEDULER, CAROUSEL, SPREADSHEET, TREE), and form/interaction primitives (buttons, links, dynamic templates). Each entry is a draggable card.
Canvas in the middle. The live preview of the dashboard you're editing. You drop palette items into containers, drag existing nodes to reposition them, and the canvas re-renders the same component tree the runtime would render.
Property panel on the right. When a node is selected, this panel exposes its inputs — every @Input() the underlying Angular component declares. Edit a property, the canvas updates in place.

There's no compile step between "drag" and "see". The designer renders with the same components the runtime uses, so what you see in design mode is what your users see in view mode.

A few of the affordances that took the most iteration:

Double-click on a palette item drops it at the canvas root. Useful when you're starting from scratch and don't want to hunt for the right drop target.
Right-click on a canvas node opens a context menu with copy/paste/delete/wrap-in-container. Copy-paste serializes the subtree to clipboard JSON; pasting deserializes it back, useful for moving a whole tile across boards.
Undo/redo with a per-edit history stack. Each property change, drop, or delete is one history entry.
Save does two writes: the canvas state goes to dom_board.boardcontent as JSON, and any CSS edits go to dom_board_sheet rows (more on that below).

There's no "design mode JSON" you can edit by hand from inside the designer — but you can open the JSON via a different route and edit it externally if you want. The designer is the recommended tool because the JSON is large.

The palette

Components are registered in the palette by registry, not hard-coded. Each component declares:

a componentType string (CHART, LIST, etc.)
a default inputs object (so a dropped component shows sensible defaults)
an icon (PrimeIcons class) for the palette card
a category (Layout, Data, Form, Custom)
an optional drop-target predicate (e.g. a TR only accepts TD children)

So when you npm install a host that registers a custom Angular widget — say, a colour picker or a map-with-clusters — it shows up in the palette automatically. The dashboards built on top can include it the same way they include the built-in CHART.

We didn't ship a fixed palette and a separate "extension point". The palette IS the extension point: register a component, it's there for the designer.

What's in `dom_board`

The schema is intentionally small:

CREATE TABLE dom_board (
    id1            INT IDENTITY(1,1) PRIMARY KEY,
    boardroute     NVARCHAR(200) NOT NULL,   -- the route the runtime opens
    boarddes       NVARCHAR(500) NULL,       -- friendly label
    boardcontent   NVARCHAR(MAX) NOT NULL    -- the JSON the designer writes
);

boardroute matches a registered Angular route (e.g. crm_home, sasa/dashboard). When the user navigates there, the runtime fetches the row, parses boardcontent, and builds the component tree.

boarddes is a label that shows up in the dashboard picker. Inconsequential.

boardcontent is the entire dashboard, serialized.

The JSON shape

The serialized component tree mirrors the canvas. Each node has:

a componentType (TABLE, TR, TD, DIV, SPAN, DATASOURCE, DATAREPEATER, CHART, etc.)
inputs (the @Input bindings — anything the property panel could edit)
components (children, for layout containers)
componentRows / componentCells (specifically for TABLE/TR)
cssClass and cssStyle if you applied per-node styling

That's deliberately HTML-ish. The runtime doesn't try to invent its own grid system; it leans on familiar containers because browsers already know how to render them at 60fps, and the JSON maps 1:1 to the DOM the designer shows.

The actual inputs set per component type can be large — a CHART has dozens of options (axis labels, palette, legend position, tooltip format, click handler, animation). The designer's property panel filters to the meaningful ones; the JSON keeps everything you customised and omits defaults.

The DATASOURCE → consumer convention

The thing that makes a dashboard JSON different from a "static page" JSON is the datasource pairing. Each chart, list, map, or kanban comes in two pieces:

{
  "componentType": "DATASOURCE",
  "inputs": {
    "route": "crm_opportunities_by_stage",
    "autoload": true,
    "uniqueName": "ds_opportunities_by_stage_1"
  },
  "metaInfo": {
    "tableMetadata": { "md_props_bag": "{...}" },
    "columnMetadata": [ /* per-column metadata for the route */ ]
  }
},
{
  "componentType": "CHART",
  "inputs": {
    "datasourceUniqueName": "ds_opportunities_by_stage_1",
    "chartType": "bar",
    "labelField": "stage_name",
    "valueField": "deal_count"
  }
}

The first emits data, the second consumes it. They're paired by uniqueName ↔ datasourceUniqueName. This is the same convention used in the rest of WUIC — list pages, edit forms, chart pages — so the designer didn't invent a new contract.

What's important here: the route on the datasource points to a registered metadata route. The runtime resolves that route against _metadati__tabelle.mdroutename, loads the table/column metadata, calls the auto-generated CRUD endpoint, and feeds the result to the consumer. The chart didn't have to know SQL. The route is the abstraction.

In the designer UI, dropping a DATASOURCE opens a route picker (autocomplete over all registered routes), and dropping a CHART or LIST after one auto-binds via uniqueName. You can also paste an already-bound pair as a unit.

CSS support: `dom_board_sheet`

Out of the box, dashboards inherit the global app theme. Often that's enough. When it's not — a "KPI tile that flips red when negative", a "card that uses the customer's brand colour", a per-board print stylesheet — we need a place to put CSS that's scoped to the board and survives runtime upgrades.

The schema:

CREATE TABLE dom_board_sheet (
    id1            INT IDENTITY(1,1) PRIMARY KEY,
    dom_boardid    INT NOT NULL,        -- FK to dom_board.id1
    sheet_path1    NVARCHAR(500) NULL   -- path to a .css file shipped with the app
);

One row per stylesheet attached to a board. A board can have many sheets (a base one + a print one + a customer-brand one, say). At dashboard load, the runtime resolves each sheet_path1 against the app's static asset folder, injects <link rel="stylesheet"> tags into the head with a board-scope marker, and unmounts them when the user leaves the route.

In the designer, the stylesheet panel lets you:

Attach an existing .css file from the app's assets to the current board (creates a dom_board_sheet row pointing at it).
Edit an attached file in an in-designer text editor. Save writes to disk + invalidates the runtime cache so the canvas re-renders with the new styles immediately.
Apply classes to nodes via the property panel — type a class name in cssClass, the canvas reflects it, and the JSON records it on the node.

This is intentionally file-based, not embedded in JSON. CSS is text. It belongs in .css files in source control. The DB just tells the runtime which files to load for which board.

The per-board scope is a CSS class wrapper — every component the designer emits gets a data-board-id="<id>" attribute, and the linked stylesheet authors are expected to scope selectors with [data-board-id="42"] .my-class. We didn't build runtime CSS-in-JS or shadow DOM scoping; the convention is plain CSS authoring discipline. For most internal apps that's been enough.

The trade-off: Angular template strings inside JSON

There's one ugly part. Some component nodes — specifically the ones that need a binding expression that the designer didn't have a UI for — carry a tag field with an Angular template string inside the JSON:

{
  "componentType": "SPAN",
  "tag": "<span [innerText]=\"computeKpi(record.amount, record.tax)\" [style.color]=\"record.amount > 0 ? '#10b981' : '#ef4444'\"></span>",
  "inputs": { ... }
}

The runtime compiles that tag string into a real Angular component (via ɵcompileComponent) at dashboard-load time and slots it in. This is how the designer lets a power-user write a KPI tile with custom formatting without writing TypeScript.

Trade-off:

Pro: any binding expression Angular supports works inside the dashboard, without us having to invent a domain-specific binding language.
Con: the JSON is no longer just data. A typo in a binding string fails at dashboard-load, not at save-time. We can't fully validate boardcontent with a JSON schema.

We mitigated this with a designer-side parser that catches the most common errors (unclosed braces, unknown variable names) before save, and a runtime fallback that logs the broken binding and renders the rest of the dashboard rather than crashing. But it's a real downside — if you want JSON purity, this isn't it.

For us the alternative was worse: invent our own expression language, document it, debug it, version it. Reusing Angular's binding syntax meant the designer's mental model is the same as the framework's mental model, and we didn't add a new layer of indirection.

What stays metadata-driven

Even with the template-string escape hatch, the data flowing into the dashboard is metadata-driven all the way down:

Data source route → resolves to _metadati__tabelle.mdroutename.
Column metadata → comes from _metadati__colonne, includes formatting, lookup resolution, validation.
Permissions → checked against _mtdt__tnt__trzzzioni__tabelle per requesting user/role.
Translations → labels resolved via the _wuic_translations table on render.

What you wrote into the dashboard is what to show (which datasources, what archetype, what styling). What you didn't write is how to fetch it — the framework figures that out from the route's metadata. Change the underlying SQL view, invalidate the metadata cache, the dashboard picks up the new shape without re-saving.

When the designer is the wrong tool

If your "dashboard" is really an app page with bespoke layout, custom interaction patterns, and three integrated forms — write it in Angular. The designer is for data presentation: a board of charts, KPI tiles, lists, maps, calendars, with light interactivity. It's not a page builder for arbitrary UI.

Try it

The public demo ships with a few dashboards under the "Home" menu. Open one, then click "Edit" in the top-right of any board — the designer opens read-write. Drag a chart from the palette, change its chartType in the property panel, attach a CSS sheet. Save. The change persists for 24 hours, then the nightly reset wipes it back to the seed.

If you want to read the source: the designer is designer.component.ts, the runtime renderer is boardcontent-runtime.component.ts, the palette registry is designer-palette-registry.ts, and the stylesheet injection lives in dom-board-sheet-loader.service.ts. The codebase chatbot (RAG post) can locate each one faster than the file tree can.

Next in this series: report generation — how a SQL view becomes a .mrt report with no per-route code, and how the report designer integrates with the same metadata schema the dashboards use. Subscribe via the RSS feed.

WUIC on Linux, natively: one binary, four DBMS choices, one shell installer

Wuic Framework — Mon, 01 Jun 2026 07:29:32 +0000

We shipped WUIC originally as a Windows / IIS stack: SQL Server, ASP.NET Core under the AspNetCoreModuleV2 hosting bundle, the whole thing managed by IIS. That's still a supported topology and the one most existing customers run. But .NET 10 is cross-platform, our metadata layer talks to four different DBMS providers, and increasingly the customers asking to evaluate WUIC don't have a Windows server lying around. So we sat down and made Linux a first-class target.

Today there's a single shell one-liner that installs WUIC on a stock Ubuntu 22.04 box, with your choice of database. This post walks through what the installer does, what each DBMS option means in practice on Linux, and what's deliberately still Windows-only.

The one-liner

curl -fsSL https://wuic-framework.com/install.sh | sudo bash -s -- \
    --dbms mssql --admin-password 'YourS3cret!' --hostname app.example.com

That's the whole install. End-to-end it runs about 15–25 minutes on a 4-vCPU box, most of which is apt install for the .NET runtime and (optionally) pip install for the Python RAG stack. Everything else is configuration.

When the script exits, you have:

The .NET app running under Kestrel at 127.0.0.1:5000, managed by systemd (wuic-core.service).
Your chosen DBMS listening on its loopback port, managed by its own systemd unit.
A Python RAG server (FastAPI + uvicorn + a LoRA-tuned reranker) at 127.0.0.1:8765, managed by wuic-rag.service. Skipped if you pass --no-rag.
nginx on :80 (and :443 with --with-tls), serving the Angular static assets directly and proxying /api/, /hubs/, /rag/ to the right backend.
Configuration in /etc/wuiccore/secrets.env, loaded by systemd at unit start. The appsettings.json on disk stays untouched — Linux-specific values are injected via env vars.

Idempotent. Re-running the one-liner on a finished box skips the already-done steps and updates only what changed.

What's in the box

The installer is structured as numbered bash scripts under scripts/linux/:

00-prereqs.sh                 OS package guardrails (apt update, curl, gnupg…)
10-install-dotnet.sh          .NET 10 runtime + ASP.NET Core
20-install-mssql.sh           SQL Server 2022 Express
21-install-mysql.sh           MySQL 8
22-write-secrets-profiles.sh  Generate /etc/wuiccore/secrets.{env,master}
23-install-postgres.sh        PostgreSQL 16 (PGDG)
24-install-oracle.sh          Oracle Database Free 23ai (Docker container)
30-bootstrap-databases.sh     Restore/create the WUIC databases (MSSQL)
31-bootstrap-mysql-databases.sh
33-bootstrap-postgres-databases.sh
34-bootstrap-oracle-databases.sh
35-provision-auth-users.sh    Seed the admin user with --admin-password
40-install-python-rag.sh      torch CPU + transformers + bge-m3 + LoRA adapter
50-publish-app.sh             dotnet publish + drop the artifact under /opt/wuiccore/
60-systemd-units.sh           wuic-core.service, wuic-rag.service, enable + start
70-nginx.sh                   vhost + reverse proxy + (optional) certbot TLS
80-smoke-test.sh              curl /api/health, dotnet --info, mssql/mysql -Q "SELECT 1"

install.sh (the one-liner) downloads a precompiled tarball, untars to /opt/wuiccore/, and runs the scripts above in order, gated by the flags you passed. The numbered scripts are also runnable individually, which is useful when you want to install only the DB (for a dev workstation) or only refresh the .NET app without touching the database (50 + 60 re-run).

The four DBMS options

We do not ship a different .NET build per DBMS. The same WuicCore.dll runs on every variant. MSSQL is the baseline and is built into the main assembly directly; for MySQL, PostgreSQL or Oracle the runtime additionally loads a satellite provider DLL (mysql.dll, postgresql.dll or oracle.dll) that sits next to WuicCore.dll in bin/ and is picked up at startup based on the dbms setting in appsettings.json (mssql / mysql / postgresql / oracle). On Linux, the installer drops the right satellite DLL into /opt/wuiccore/app/bin/ based on --dbms. All four are exercised by the same test suite (~600 metadata-driven tests running against the live backend), so a passing run on one DBMS exercises the same call paths as a passing run on the others. Here's what each one actually means:

`--dbms mssql` (SQL Server 2022 Express on Linux)

Microsoft ships SQL Server 2022 native for Ubuntu 22.04. The installer adds the Microsoft apt repo, installs mssql-server, runs mssql-conf setup non-interactively with the auto-generated SA password (stored in /etc/wuiccore/secrets.master, mode 0600), binds the listener to 127.0.0.1:1433, and loads the seeded databases via either RESTORE DATABASE from the .bak (~2s) or the streaming .sql (~25 min) depending on the tarball variant you downloaded.

`--dbms mysql` (MySQL 8 on Linux)

The path for cost-sensitive cloud deploys (cheap managed MySQL is everywhere). The installer adds Ubuntu's stock MySQL 8 (apt install mysql-server), binds to 127.0.0.1:3306, runs mysql_secure_installation equivalents non-interactively, and loads the schema from dbms/scripts/first-run/*.mysql.sql. The provider is mysql.dll, loaded by the .NET runtime via the same hot-swap mechanism the Windows host uses. The metadata layer, the auto-generated CRUD endpoints and the scaffolder don't have per-DBMS branches — they emit ANSI SQL where possible and call into the provider for the edge cases (paging keywords, JSON column read/write, MERGE semantics).

`--dbms postgres` (PostgreSQL 16 via PGDG)

Same provider mechanism (postgresql.dll). 23-install-postgres.sh adds the PGDG repo (we need ≥16 because the seeded pg_dump files were generated against 16.x), installs postgresql-16, binds to 127.0.0.1:5432, and loads the seeded schemas from dbms/scripts/first-run/*.postgres.sql. End state: systemd-managed Postgres, secrets in /etc/wuiccore/secrets.env, the .NET app picks up dbms=postgresql from the env var and loads the right provider.

`--dbms oracle` (Oracle Free 23ai via Docker)

Oracle is the awkward one. Oracle Database Free 23ai ships as an .rpm targeting OL/RHEL; running it natively on Ubuntu requires alien conversion plus glibc/kernel workarounds that Oracle doesn't officially support. So on Linux we run it in Docker, using the community-maintained gvenzl/oracle-free:23-slim image (Apache-2.0 wrapper around the official Oracle Free 23ai binaries, distribution governed by Oracle's Free Use License). 24-install-oracle.sh installs Docker if not present, pulls the image, runs the container bound to 127.0.0.1:1521, generates the SYSTEM/PDB passwords, and waits for SELECT 1 FROM DUAL to succeed. 34-bootstrap-oracle-databases.sh then loads the seeded schemas. The Windows dev side standardized on the same image (the regeneration scripts under scripts/regen-firstrun-oracle.ps1 dump from localhost:1521/FREEPDB1 against it), so the schema we ship is the schema we develop against.

Combinations

install-all.sh also accepts --dbms both (mssql + mysql side-by-side) and --dbms all (all four side-by-side). Useful when you want one box that can host every variant and switch the active one by env var, typically a test rig.

What's actually the same across all four

The whole point of the provider-drop-in story is that the application layer doesn't care which DBMS is underneath:

CRUD endpoints are auto-generated from the metadata route once. The same GET /api/Meta/AsmxProxy/<route>.crudRead works on every DBMS; the provider translates to whatever SQL dialect is appropriate.
The scaffolder reads INFORMATION_SCHEMA (or the Oracle / Postgres equivalent) and produces the same metadata rows. A table scaffolded on Postgres has the same metadata shape as the same table on MSSQL.
The metadata cache, the runtime templates, the designer, the dashboard renderer — these don't know which DB you picked. They read _metadati__* and run.
The Angular bundle is identical. Same WuicSite/wwwroot/ artifact regardless of backend DBMS.

What does change per-DBMS:

The satellite provider DLL loaded alongside WuicCore.dll for non-MSSQL backends (and the connection string format in appsettings.json).
The seed SQL loaded at first-run: tutorial-data.mssql.sql vs .mysql.sql vs .postgres.sql vs .oracle.sql, generated by an internal dotnet publish -GenerateSqlScripts script that dumps a reference instance per DBMS. Same data, four dialects.
A small set of SQL-builder code paths for things the DBMSs handle differently (paging keywords, MERGE vs ON CONFLICT, JSON column read/write). These live in the main assembly for MSSQL and in the satellite DLL for the other three — you don't see them from the app layer.

What's deliberately still Windows-only

A couple of things didn't come over and probably never will:

IIS hosting. On Linux we use Kestrel + nginx instead. Same .NET app under the hood, different process manager. IIS-specific tooling (appcmd, the IIS Manager UI, WinRM remote management) doesn't apply.
SQL Server Management Studio integration helpers. SSMS is Windows-only. The Linux installer ships mssql-tools18 (sqlcmd, bcp) for the same CLI workflows.

Tarball variants

The install.sh one-liner downloads one of three Linux tarballs, depending on what you ask for:

wuic-framework-v<ver>-linux-x64.tar.gz (runtime, ~600 MB) — pre-compiled dotnet publish artifact + Angular bundle + linux installer scripts + DB seed SQL. Default for the operator-running-a-service path.
wuic-framework-v<ver>-linux-x64-src.tar.gz (source, ~80 MB) — the .cs and .ts source tree, for developers cloning to build locally. Defaults extract to /opt/wuic-src/ owned by ${SUDO_USER} so the dev can dotnet build without sudo.
Both, if you don't pass --demo-only or --src-only. Useful on a single-box dev environment.

Either variant uses the same numbered install scripts and the same systemd units. The difference is whether /opt/wuiccore/app/ is a pre-built artifact or a dotnet run --project /opt/wuic-src/... invocation.

When Linux is the wrong call

If your shop already has a Windows AD domain and an IIS production environment with PowerShell DSC / Ansible Windows playbooks already configured, the IIS deploy is still the path of least resistance. Linux is the right answer for fresh deploys, cost-sensitive cloud (no Windows licensing), or environments where ops already lives in Linux land. We don't think there's a wrong choice — the application code is the same.

Try it

The public demo currently runs the Windows/IIS topology. The Linux deploy is what you'd run on your own server. The one-liner is hosted at install.sh — read it before piping to bash if that makes you uncomfortable (it's a 700-line script, mostly comments). The tarballs are listed on the downloads page.

The Linux installer source tree lives in scripts/linux/ if you want to read each step. The codebase chatbot (RAG post) can find any specific step by description if you don't want to navigate manually.

Next in this batch of posts: the wizard architecture — multi-step forms with conditional branches, all driven by metadata. Subscribe via the RSS feed.

Why we built a metadata-driven Angular framework instead of using Retool

Wuic Framework — Sun, 31 May 2026 14:39:07 +0000

When you start a B2B project and someone says "we'll use Retool, it's faster", they're usually right. For the first three internal tools, they always are. Drag-and-drop panels over a Postgres database, an SSO connector, a couple of approval flows — done in two afternoons. We were that team. For a year and a half, we shipped real value through Retool dashboards.

This is the story of why we eventually stopped, and why we ended up building WUIC — a closed-source, metadata-driven Angular framework — instead of switching to one of the obvious open-source alternatives.

The wall

Three things happened in the same quarter that made Retool stop feeling like a good fit:

1. The dashboards became the product. What started as internal admin panels grew into client-facing CRM screens. Customers saw them, customers complained about them. Suddenly we needed pixel-level control over forms, custom validation messages our designer cared about, dark mode that actually matched the rest of our brand, mobile views that didn't look like a Retool dashboard squashed into a phone.

2. The bill scaled with users, not with value. Retool's per-end-user pricing is generous when 8 people log in. It's painful when 800 do. Our usage curve was about to flip from "internal tools" to "operations platform served to the customer", and the math stopped working.

3. We hit the customisation cliff. Once you have JS code in Retool that talks to JS code in Retool that talks to JS code in Retool, the cliff is real. You're writing a frontend inside a frontend, with no IDE that understands the bindings, no version control that diffs cleanly, no CI that runs. Code review becomes "look at this screenshot of the canvas". We've been there. It's not where you want to live.

So we evaluated alternatives.

What we considered

The shortlist was the usual: Refine (React framework), Budibase (open-source low-code platform), AppSmith (open-source Retool clone). Each had something we liked.

Refine in particular is technically excellent — if your team is React-fluent and wants a hand-written admin UI with full code review, it's a great pick. The reason we passed wasn't the framework, it was the math: we'd estimated 18 months of full-time work to reach the feature surface our existing Retool screens already covered (workflow engine, report builder, dynamic permissions, multi-tenant audit log, mobile auto-layout). Eighteen months of building those wheels instead of the actual product.

Budibase and AppSmith were closer to what we wanted in spirit — drag-and-drop, but self-hosted and open-source — but each had its own ecosystem to learn, and migrating data + auth + workflows from Retool to either of them was a non-trivial port. The cliff would just move; we'd hit it again at a different angle.

We also considered just keep paying Retool more. We'd be lying if we said we didn't crunch those numbers. The blocker there was less the price and more the customisation cliff: even with the Enterprise tier, we couldn't ship the UI quality our customers were starting to expect.

The insight

Around that time we noticed something about our Retool screens. Almost every form, list and dashboard was implicit metadata. The columns came from the database. The validation rules came from the column types and the business constraints. The buttons came from the route's permitted actions. The lookup widgets came from foreign keys.

We were typing all this into Retool's UI by hand. Then typing similar things into our backend's input validation. Then typing similar things into our API documentation. Three places, slightly inconsistent, drifting over time.

The thought was: what if the metadata was the source of truth, and the UI was a pure function of it?

Not "low-code" — there's still real code to write, and we wanted that. Less code. Specifically: zero hand-written boilerplate for the 80% of screens that are obvious from the schema, and full Angular freedom for the 20% that aren't.

What WUIC actually is

WUIC is two databases worth of metadata + a runtime that turns it into a working Angular app:

A routes table describing every entity in your domain — name, table, default permissions, default form layout, anything that's true of the entity as a whole.
A columns table describing every field — type, label, validation rules, lookup target, visibility per role, default styling, callbacks.

Given those, the runtime renders:

Auto-CRUD list pages with sort/filter/group/inline-edit out of the box.
Edit forms with the right widget per type (text, lookup, file upload, rich text, date with locale formatting, …).
A dashboard designer where you drag widgets onto a canvas, bind them to a route, save — the dashboard goes live.
A report designer that produces PDF + Excel from the same metadata.
A workflow engine where each step is a route, and the graph between them is more metadata.
A mobile responsive layout that derives card stacks from the same column metadata that drives desktop tables.
An in-product RAG chatbot that answers questions about the data + the framework itself (more on that in the next post).

You can drop down to plain Angular components anywhere — <wuic-list-grid> is a regular standalone component, you can wrap it, replace it, override its template. We deliberately kept the framework at "code-saver" level rather than "low-code platform". Less typing, full developer control.

What's not in the box

It's important to be honest about what isn't a good fit for this approach.

One-off internal panels with weird datasources. If you need to wire a button on a dashboard to a Slack webhook, that's a Retool thing. WUIC assumes your data lives in SQL. We have integrations, but the framework's heart is database-driven.

Teams without a SQL expert. Metadata is conceptually simple but it lives next to your schema. If nobody on the team is comfortable opening SQL Server Management Studio, the value proposition collapses.

Greenfield mobile-first products. We do mobile, and it works, but a product where mobile is the primary surface should probably start mobile-first. WUIC starts desktop-first and reflows down.

The 18 months in retrospect

It's been roughly 18 months since we cut the first Retool screen. The trade-off, blunt:

Throughput on new screens went up. The 80% of screens that are obvious from the schema take minutes, not days.
Throughput on the first screen went down. There's now a framework to learn, conventions to follow, metadata to populate. A non-developer can't ship in a single afternoon any more.
Customisation cliff shifted from "Retool's JS sandbox" to "Angular and TypeScript". Higher floor, much higher ceiling. Code review works. Git diff works. CI works.
Per-user cost dropped to zero. Per-developer license, fixed annual. The math now scales.

If you're early-stage and doing 5 internal panels with 10 internal users, we'd still tell you to use Retool. It really is faster. The break-even point in our case was around screen #15 + first customer-facing dashboard.

If you're past that, and you want to learn about the alternatives we considered side-by-side — including how WUIC compares against Refine, Budibase, and AppSmith feature-by-feature — there's a comparison page for that, and the feature gallery shows the framework actually doing things. Or skip the talking and try it.

The next post in this series digs into one specific feature — the in-product RAG chatbot — and why we ended up building one from scratch when "just integrate ChatGPT" would have shipped in a week. Spoiler: it's about citations.

DEV Community: Wuic Framework

Mobile-first auto-layout with zero config: how WUIC reflows enterprise tables on a phone

The default behavior

Where the swap lives

List-grid: runtime row-template swap (TS)

Customizing the card: mobileCardTemplate

Edit-form: CSS-only reflow (SCSS)

What we don't try to handle automatically

The breakpoint

Performance corner

When it's not enough

Try it

Enterprise reports in three steps: SQL view drag-and-drop designer menu entry

The example

Scaffold the view as a metadata route

Design the report against the route

Where the .mrt goes on disk

What's reused from the rest of the framework

A note on the dictionary

Naming discipline (a real warning)

What the report engine does NOT do

Try it

From SQL table to working CRUD form in 30 seconds: a metadata-driven scaffolding approach

The 30 seconds, end-to-end

What the scaffolder actually inspects

What ends up in metadata

The 80/20

What scaffolding does not do

How it scales

When NOT to scaffold

Try it

The chatbot's toolbox: the actions an LLM can apply to your app

Grid actions

propose_toolbar_action

propose_row_action

Conditional styling

propose_table_style

propose_column_style

Cell rendering and form titles

propose_display_formula

propose_form_title_formula

Form callbacks

propose_default_value_callback

propose_custom_validation

propose_selection_changed

propose_lifecycle_callback

Metadata

propose_simple_metadata_update

propose_metadata_column_create

SQL (super-admin)

propose_sql_metadata_field

Designer canvas

propose_designer_inject

Before it acts: asking for the schema

The quiet tools

Why a fixed toolbox

The architecture of an in-product RAG chatbot: from your prompt to the answer

What "in-product RAG" means here

The journey of a single prompt

A leaner prompt: schema on demand

The shape of the index

Hybrid retrieval, not pure vector

Fine-tuning the cross-encoder

Translating Italian queries

Why Claude for synthesis

Serving it natively on .NET

What didn't work

What's the chatbot actually for?

Try it

The dashboard designer: drag-and-drop that writes JSON metadata, not Angular code

The designer

The palette

What's in dom_board

The JSON shape

The DATASOURCE → consumer convention

CSS support: dom_board_sheet

The trade-off: Angular template strings inside JSON

What stays metadata-driven

When the designer is the wrong tool

Try it

Customizing the card: `mobileCardTemplate`

`propose_toolbar_action`

`propose_row_action`

`propose_table_style`

`propose_column_style`

`propose_display_formula`

`propose_form_title_formula`

`propose_default_value_callback`

`propose_custom_validation`

`propose_selection_changed`

`propose_lifecycle_callback`

`propose_simple_metadata_update`

`propose_metadata_column_create`

`propose_sql_metadata_field`

`propose_designer_inject`

What's in `dom_board`

CSS support: `dom_board_sheet`

`--dbms mssql` (SQL Server 2022 Express on Linux)

`--dbms mysql` (MySQL 8 on Linux)

`--dbms postgres` (PostgreSQL 16 via PGDG)

`--dbms oracle` (Oracle Free 23ai via Docker)