2 posts tagged with "frontend"

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 2019 the generated frontend and backend started to look more like a runtime, not a collection of pages.

The diff shows work around java_view_base_view_page.jsp, generated checker templates, generated scripts, event processors, base constants, locale services, React object base components, dashboards, tables, profile pages, permission pages, and step forms.

Base View Pages​

The generated Java view layer introduced reusable base view concepts:

• object view pages
• list-of view pages
• view models
• profile and preference views
• permission-aware presentation

This helped separate generated page behavior from individual object templates. Repeated page mechanics moved into base templates, while object-specific code stayed small.

Generated Validation Surface​

Checker generation also became more visible:

• base checker templates
• object checker templates
• checker manager templates
• update parameter checks
• reference parameter update checks

Validation was moving closer to generated domain behavior. Instead of relying on handwritten service guards, the generator could emit repeatable checks from model metadata.

Events and Step Forms​

Event and step-form templates appeared beside the normal CRUD forms.

That mattered because real business apps rarely stop at simple create/update pages. The generator began to support process-shaped UI and backend hooks, such as change events, staged forms, and generated action wiring.

Locale and Presentation Polish​

The React templates also gained more presentation behavior:

• locale lookup
• permission-based action display
• generated operation columns
• table sorter state
• dashboard and profile variants

These were not model additions. They were generated application capabilities that made the output closer to something teams could use directly.

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:

• SmartList helpers 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:

1. model metadata describes fields and relationships
2. backend code exposes list/search operations
3. frontend code renders tables and forms
4. 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.