React DVA Admin Generation
Historical note: This article documents an earlier TeaQL generation target. Early versions emitted backend templates, UI pages, mobile clients, and service scaffolding directly into application workspaces. Modern TeaQL has moved to a clearer boundary: generation produces versioned libraries, deterministic business APIs, query DSLs, and runtime capabilities that applications consume as artifacts. This is more friendly to AI-assisted coding and DevOps because AI agents can focus on business workflows, integrations, tests, and product behavior, while generated capabilities are reviewed, tested, published, upgraded, and rolled back through normal dependency and release pipelines.
In 2017 the generator started to produce a real web application layer.
The most active template areas shifted from only Java persistence to sky/react and supporting Java templates. New generated files covered DVA app entry points, object apps, models, services, tables, create forms, update forms, dashboards, routers, search views, and locale resources.
Generated Object Applications
The React templates turned each domain object into a predictable frontend module:
- route registration
- model state
- service calls
- table rendering
- create and update forms
- search screens
- dashboard entry points
This was the frontend equivalent of generated DAO and manager code. Each object received the same operational surface, and project-specific customization could be layered around it.
SmartList and User Context
The Java side also evolved to support generated frontend needs:
SmartListhelpers for list behavior- generated
UserContext - base manager methods
- common base entity behavior
- operation tokens
- locale resources
The frontend was not generated in isolation. It drove backend improvements so generated pages had the metadata, permissions, labels, and list behavior they needed.
Search and Presentation
Generated React search pages and generated Java presentation descriptors started to connect.
That created a full loop:
- model metadata describes fields and relationships
- backend code exposes list/search operations
- frontend code renders tables and forms
- locale and presentation metadata keep the generated UI usable
Why This Stage Mattered
This stage moved code generation from "generate the backend boilerplate" to "generate the operational app shell."
The generated application was still template-driven, but the feature surface became much broader: persistence, service methods, search screens, forms, tables, routing, and localization all came from the same model.
