2 posts tagged with "search"

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 2022 the generator's search layer became a real typed DSL.

The most important files were java_search_dsl_base.jsp, java_search_dsl_request.jsp, generated DAO helpers, SmartList, base entity templates, SQL logger templates, and scenario/data-manager builders. The code changes point to a clear feature: generated request objects became the main way to express reads, filters, selects, ordering, aggregation, and graph traversal.

BaseRequest as Generated Query Contract​

The generated BaseRequest carried the common query model:

• selected fields
• parent selects
• child selects
• search criteria
• order by clauses
• pagination
• aggregation
• group by requests
• dynamic attributes
• cache hints

Object-specific request templates then generated typed methods such as filterBy..., select..., unselect..., and orderBy....

Relationship-Aware Search​

The request templates generated relationship-aware filters:

• filter by parent request
• filter by child request
• refine ids through nested request results
• select parent objects
• select child lists
• unselect nested relations

That made the query API model-driven. Developers could express graph-shaped reads without manually assembling joins or ad hoc SQL fragments.

Safe Delete and Update Semantics​

The generated DSL also added safer write semantics:

• safe delete
• remove and recover naming
• update operation support
• version-aware id handling
• list save improvements

This continued the same principle as generated reads: common business data operations should have deterministic generated APIs.

Aggregation, JSON Search, and Logging​

The search layer also gained:

• count fixes
• sum and average helpers
• month and year aggregation
• JSON search expressions
• list search from JSON
• aggregation cache hints
• SQL logging helpers

The result was a generated query surface that could serve UI screens, reports, dashboards, and API consumers without falling back to handwritten SQL for every case.

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.