Cabloy

Appearance

Backend Metadata to Frontend Table Actions Source Reading Map ​

This page is a practical source-reading companion for one narrow fullstack question:

if I need to trace one Student row-action chain across backend metadata, generated contract follow-up, and frontend action resources, which files should I open first, and in what order?

Use this page together with:

TIP

Mixed-chain reading path

  1. Backend Metadata to Frontend Table Actions — understand the mixed contract chain conceptually
  2. Backend Metadata to Frontend Table Actions Source Reading Map — trace the same Student row-action chain in file order

You are here: step 2. Previous recommended page: Backend Metadata to Frontend Table Actions.

Why this page exists ​

The current mixed-chain explainer page already answers the conceptual question well:

  • backend metadata chooses frontend action resources
  • generated API/model follow-up can join that same thread when custom actions need backend endpoints
  • the visible row action is only the last step of the chain

What it does not isolate directly is the shortest source-order path through one real Student row-action thread.

This page fills that gap.

It is a file-order map, not another runtime explainer.

How to use this page ​

For the two paths below:

  1. start with the conceptual mixed-chain page first
  2. read the first source file to identify the current source of truth
  3. follow the handoff only until you can answer the question you actually have
  4. stop before you drift into deeper table/runtime internals unless they are really needed

1. Built-in row-action chain ​

Use this path when your question is about:

  • how one built-in row action becomes visible
  • how actionOperationsRow composes visible child actions
  • where backend metadata stops and frontend action resources start

Read the docs first ​

Then read source in this order ​

  1. vona/src/suite/a-training/modules/training-student/src/dto/studentSelectResItem.tsx
  2. zova/src/suite/cabloy-basic/modules/basic-table/src/bean/tableCell.actionOperationsRow.tsx
  3. zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx
  4. zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockTable/controller.tsx

What each file clarifies ​

  • studentSelectResItem.tsx shows the backend-owned row DTO metadata that chooses basic-table:actionOperationsRow and the visible child actions inside it
  • tableCell.actionOperationsRow.tsx shows how the frontend runtime filters those child actions by permission and renders them through nested action resources
  • blockPage/controller.tsx shows how schemaRow, permissions, and list data are exposed from the stable resource owner into the page runtime
  • blockTable/controller.tsx shows the bridge from page runtime into ZTable

2. Custom action chain with generated contract follow-up ​

Use this path when your question is about:

  • how a custom row action such as summary or deleteForce joins the mixed chain
  • where the forward-generated API/model path enters
  • how the visible action stays thin while backend truth and resource ownership remain coherent

Read the docs first ​

Then read source in this order ​

  1. vona/src/suite/a-training/modules/training-student/src/controller/student.ts
  2. vona/src/suite/a-training/modules/training-student/src/dto/studentSelectResItem.tsx
  3. zova/src/suite/a-training/modules/training-student/cli/openapi.config.ts
  4. zova/src/suite/a-training/modules/training-student/src/api/trainingStudent.ts
  5. zova/src/suite/a-training/modules/training-student/src/model/student.ts
  6. zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionSummary.tsx
  7. zova/src/suite/a-training/modules/training-student/src/bean/tableCell.actionDeleteForce.tsx
  8. optional downstream handoff:
    • zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockPage/controller.tsx
    • zova/src/suite/cabloy-basic/modules/basic-page/src/component/blockTable/controller.tsx

What each file clarifies ​

  • controller/student.ts shows the backend source truth for custom endpoints such as summary/:id and deleteForce/:id
  • studentSelectResItem.tsx shows the backend row metadata that inserts the custom row actions into the operations column
  • openapi.config.ts shows the frontend module ownership rule for generated OpenAPI operations
  • api/trainingStudent.ts shows the generated typed API surface that the frontend can consume
  • model/student.ts shows the thin semantic facade over the stable resource owner
  • tableCell.actionSummary.tsx shows a visible action that stays thin and delegates summary behavior into the model/API path
  • tableCell.actionDeleteForce.tsx shows the same pattern for force-delete behavior
  • blockPage and blockTable are only needed when the question becomes “how does the list runtime carry that row schema into visible table output?”

What this page does not re-explain ​

This page deliberately does not re-teach:

Its job is only to provide the shortest file-order path through one mixed Student row-action chain.

Final takeaway ​

The cleanest way to read a mixed Student row-action chain is not to jump directly into either the backend bridge docs or the deepest table runtime files.

Start from the backend row metadata that chooses the visible action resources, then follow the custom forward-generated path only when the action semantics actually require new backend endpoints.

Released under the MIT License.

Copyright © 2016-present Cabloy