Zzzz
43 lines
1.4 KiB
Markdown
43 lines
1.4 KiB
Markdown
# State Management
|
|
|
|
> State conventions for server-rendered JSP pages.
|
|
|
|
---
|
|
|
|
## Overview
|
|
|
|
This project does not use React/Vue state libraries or SPA stores. State should
|
|
flow through the Servlet/JSP request cycle unless a future explicit decision
|
|
changes the frontend architecture.
|
|
|
|
---
|
|
|
|
## State Categories
|
|
|
|
- Request attributes: page data, validation errors, form echoes, table rows,
|
|
reports, and short result messages for a single render.
|
|
- Session attributes: authenticated user identity, role, permission summary,
|
|
and short-lived flash-style messages when redirects are used.
|
|
- Database state: books, categories, readers, borrowing records,
|
|
administrators, permissions, and logs stored in MySQL through services/DAOs.
|
|
- Form state: submitted by browser forms to Servlets and re-rendered from
|
|
validated request attributes on failure.
|
|
|
|
---
|
|
|
|
## Rules
|
|
|
|
- Keep business state in MySQL, not hidden fields or long-lived browser state.
|
|
- Keep permission decisions server-side.
|
|
- Use redirects after successful mutations such as create/update/delete,
|
|
borrow, return, renew, and permission changes.
|
|
- Do not add Redux, Pinia, client caches, or SPA routing state unless the
|
|
developer explicitly introduces that stack later.
|
|
|
|
---
|
|
|
|
## Page Scripts
|
|
|
|
Small JavaScript can improve interaction, such as confirm dialogs or local form
|
|
helpers, but server-side validation and service-layer rules remain mandatory.
|