3.8 KiB
Frontend Action Slots Design
Goal
Generate user-facing frontend pages from the system module blueprint, then attach business workflow actions to explicit page slots such as detail primary buttons and list row actions.
Problem
The current blueprint flow already separates static application modules from executable business actions:
AppBlueprintDesignstores roles plusfrontendMenusandadminMenus.BusinessActionDesignstores executable action details such asownerTable,requestFields,ruleChecks, andeffects.
Generated frontend templates still attach actions by table only. A table-owned action appears in both the generated list page and detail page because templates iterate tableBusinessActions. This cannot express cases such as:
- Book catalog is the only frontend menu.
- Book detail is a child page, not a top-level menu.
- Borrow and reserve appear on book detail.
- Return appears in My Borrows row actions.
- Cancel reservation appears in My Reservations row actions.
Architecture
Add a small frontend page composition layer between menus and business actions.
System module blueprint gains frontendPages. A menu can point to a page with pageCode, while child pages such as details can use parentPageCode. Business actions gain uiBindings, each of which names a target page and a supported slot.
The generator keeps existing table-based action rendering as a compatibility fallback. When uiBindings are present, frontend templates render by slot instead of blindly rendering every action for the table.
DSL
frontendPages item:
{
"code": "book_detail_page",
"name": "Book Detail",
"menuCode": "book_catalog",
"parentPageCode": "book_catalog_page",
"path": "/books/:id",
"pageType": "detail",
"tableName": "book_info"
}
uiBindings item:
{
"target": "frontend",
"pageCode": "book_detail_page",
"slot": "detail.primaryActions",
"component": "button",
"inputMapping": {
"book_id": "detail.book_id"
},
"refresh": "detail"
}
Supported first-phase slots:
list.toolbarActionslist.rowActionsdetail.primaryActionsdetail.secondaryActionsform.footerActions
First implementation renders list.rowActions and detail.primaryActions. Other slot names are validated and preserved for later template expansion.
Data Flow
- AI generates system module blueprint with menus and pages.
- Frontend sends confirmed app blueprint when generating business blueprint.
- Business blueprint prompt includes saved schema and confirmed app blueprint.
- AI returns actions with
uiBindings. - Backend normalizes and validates table, field, page, slot, component, and refresh values.
GenProjectServiceImplbuildsslotBusinessActionsand exposes it to Velocity.- Vue3 frontend templates render row and detail buttons from slot-specific action lists.
Compatibility
Existing saved projects without frontendPages or uiBindings still work:
- Menus render as they do today.
- Backend action code still uses
ownerTable. - Frontend action buttons fall back to table-owned actions when no slot bindings exist.
Validation
Validation rejects:
- Unknown page codes in
uiBindings. - Unknown slot names.
- Unknown target values other than
frontendandadmin_frontend. - Unknown component values other than
button,link, anddropdown-item. - Unsafe input mapping expressions.
For first phase, page validation is strict when the app blueprint is present and lenient when legacy actions have no bindings.
Testing
Tests cover:
- DTO serialization and task worker propagation of app blueprint into business blueprint requests.
- Validator acceptance of valid frontend page bindings and rejection of unknown page codes.
- Velocity context grouping of actions into
slotBusinessActions. - Vue3 template seed rendering of
list.rowActionsanddetail.primaryActions.