Skip to main content

Metadata-Driven Search and Forms

· 2 min read
TeaQL Code Gen
TeaQL Code Gen
Core Contributor

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.

By 2018, the generator was no longer just expanding template count. It was strengthening the metadata model behind those templates.

The code changes repeatedly touched FieldDescriptor, ObjectDescriptor, ObjectCollection, PresentObjectDesc, query criteria templates, React object pages, dashboards, update forms, create forms, editable tables, and form processors. The recurring pattern was clear: generated code needed richer metadata to produce better behavior.

Descriptor Layer Becomes Central​

FieldDescriptor and ObjectDescriptor became the shared language for:

  • Java field and column generation
  • React table columns
  • search form fields
  • parent and child relationship handling
  • presentation descriptors
  • permission and profile views

This reduced the number of one-off rules inside templates. Instead of each template rediscovering field meaning, descriptors carried more of that meaning.

Generated Search Criteria​

The Java backend gained stronger query criteria generation:

  • base query criteria
  • DAO naming helpers
  • generated search methods
  • parent and child filtering
  • list and paging support

This prepared the path for the later Request DSL. Search was becoming a generated API, not just a controller convention.

Generated Form Runtime​

The form-related code also became more systematic:

  • base form specs
  • form processors
  • object view detail templates
  • create and update form bodies
  • editable table templates

That made UI generation less page-by-page and more rule-driven. The generator could infer common form behavior from the domain model and presentation metadata.

Why This Stage Mattered​

The main feature was not one specific screen. It was the move toward metadata-driven generation.

Once descriptors became expressive enough, the generator could produce backend APIs, frontend forms, search screens, and presentation views consistently. That is the foundation needed for typed query generation and deterministic business APIs later.