Concepts

Mon, 01 Jan 0001 00:00:00 +0000

Concepts — what we’re actually building#

This is the no-jargon tour. Whether you’re a product owner trying to understand what the team is building, a Java developer new to the frontend, or a React developer new to Spring, the vocabulary below is all you need to make sense of the rest of the guide.

The 30-second version#

A Palmyra app has four moving parts:

A model — a Java class that describes one kind of record (a Department, an Employee).
A handler — a small Java class that says “publish this model as an HTTP endpoint.”
A store — a JavaScript helper that knows how to call that endpoint from the browser.
A grid or form — a React component that reads from a store and puts rows on the screen.

You tag the Java classes with a few annotations; Palmyra fills in the SQL, the URL routing, the paging, the JSON parsing, and the HTTP calls. You write the business logic and the screens — not the plumbing.

Recap and next steps

Mon, 01 Jan 0001 00:00:00 +0000

Recap and next steps#

You’ve built a two-entity admin console end-to-end: annotated schema on the backend, Mantine screens on the frontend, with a foreign-key lookup connecting the two. This page sums up what’s wired and points at where to take the app next.

What’s wired, end to end#

UI	API call
Department grid	`GET /api/department?...` via `SummaryGrid`’s internal grid store
Department view	`GET /api/department/{id}` via `PalmyraViewForm`
Department new / save	`POST /api/department` / `POST /api/department/{id}`
Employee grid	`GET /api/employee?...` via `SummaryGrid` — dotted `department.code` column projects the FK join inline
Employee view	`GET /api/employee/{id}` via `PalmyraViewForm`
Department lookup (inside Employee form)	`GET /api/department?name=...&_limit=...` via `MantineServerLookup`’s lookup store
Employee new / save	`POST /api/employee` with payload `{ department: { id } }`
Employee edit / save	`POST /api/employee/{id}` with the same FK shape