10 posts tagged with "code-generator"

The code generator evolved from a prototype into a production-ready Spring Boot generation engine.

Code Generator​

Spring Boot Generation Engine​

• 26 files changed, 467 lines added
• Templates migrated to Spring Boot STG (StringTemplate)
• Support for lib and ZIP file imports
• Auto-generated UserContext

Domain Model Reuse​

DomainParser now supports importing domain models from local filesystem paths, ZIP archives, and remote library references.

Runtime Enhancements​

Checker Validation Framework​

Automatically validates domain objects before persistence to ensure data integrity:

+ SQLRepositorySchemaHelper: added checker validation (66 lines)
+ Checker: validates entity constraints before save/update

EntityDescriptor Metadata​

A metadata object describing the full structure of an entity, including children, properties, and relationships.

Other Improvements​

• TypeCriteriaParser: Filter entities by type hierarchy
• Smart IN Optimization: Single-value IN automatically becomes =, NOT IN becomes !=
• SmartList: Supports get(index) and size()
• GitHub Actions CI/CD: Automated publishing to GitHub Packages

TeaQL did not appear from nowhere, and it is not simply a rename of an old generator.

It came from a long engineering lineage around one persistent problem: business software repeats the same structures across projects. Domain models, relationships, permissions, queries, validation, workflows, persistence rules, and presentation metadata appear again and again. The hard question is not whether code can be generated. The hard question is where the generation boundary should live.

Before the Git History​

The earliest internal version of this direction was built in 2003.

That first version was already focused on reducing repetitive business application code in enterprise systems. The visible Git history of web-code-generator starts on April 1, 2016, but that commit should be read as a preserved snapshot of an older internal lineage, not as the beginning of the idea.

This history matters because the core problem stayed consistent for more than two decades. What changed was the shape of the generated output.

The Workspace Generation Era​

The early web-code-generator approach generated source code directly into application workspaces.

That made sense for the development model of its time. A team could describe domain objects and generate a working application surface:

• Java POJOs, DAO interfaces, JDBC mappers, SQL, and manager services
• JSP and later React DVA admin pages
• Android, Swift, and miniapp client templates
• generated forms, tables, dashboards, search pages, and locale resources
• IAM, validation, event, and service scaffolding

This proved that model-driven generation could cover much more than CRUD. It could generate a large part of the repetitive structure around real business systems.

But generating source code into the developer workspace also has a cost. Generated files become mixed with handwritten files. Reviews get noisy. Upgrades create large diffs. AI coding agents must search through many repeated files before finding the business logic that actually matters. DevOps teams have to govern generated behavior indirectly through each application repository.

The Transition After 2022​

After 2022, web-code-generator became less of a standalone product story and more of the engineering transition path into TeaQL.

Some important work still happened in the old repository during this overlap period:

• Request DSL improvements
• JSON search and list search
• aggregation, count, sum, average, month, and year support
• safe delete and recovery semantics
• SQL logging
• multi-database JDBC template improvements
• override-class and large-result handling

These were not just old-template maintenance tasks. They helped validate the capabilities that TeaQL later moved behind a cleaner library and runtime boundary.

The TeaQL Boundary​

Modern TeaQL moved the generation boundary.

Instead of scattering generated source files across application workspaces, TeaQL focuses on generating versioned libraries, deterministic business APIs, query DSLs, object graph persistence behavior, and runtime capabilities that applications consume as artifacts.

That difference is important.

The old model was:

domain model -> generated source files inside the application workspace

The TeaQL model is:

domain model -> generated library/runtime artifact -> application dependency

The generated output becomes something that can be tested, published, versioned, upgraded, rolled back, and shared through normal release pipelines.

Why This Matters for AI Coding​

AI-assisted coding changes the cost of generated source.

If thousands of generated files live beside handwritten business code, the AI agent has to navigate a noisy workspace. It may spend context on repeated scaffolding instead of the business workflow, integration, test, or product behavior that needs attention.

TeaQL's newer boundary gives AI agents a cleaner surface:

• generated behavior lives behind stable APIs
• business code depends on deterministic query and persistence contracts
• repetitive infrastructure becomes library behavior
• application changes stay focused on business intent

This does not remove generation. It makes generation more governable.

Why This Matters for DevOps​

The same boundary helps DevOps.

Generated capabilities can move through normal engineering controls:

• CI checks
• automated tests
• package publication
• dependency upgrade
• release notes
• rollback
• multi-environment deployment

That is much cleaner than repeatedly regenerating large source trees inside many application repositories.

How to Read the Old History​

The older web-code-generator articles should be read as capability history.

They document how the system learned to generate persistence code, service code, frontend pages, mobile clients, forms, validation, search, aggregation, and runtime helpers. Some technologies mentioned there, such as JSP, DVA, older Android and Swift templates, or Taro miniapp generation, are no longer the current recommended stack.

Their lasting value is not the specific old framework. Their lasting value is the engineering lesson: complex business software has repeatable structures, and those structures should be generated from a domain model.

TeaQL is the AI-era productization of that lesson.

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.

In 2021 the generator added a new backend target: Spring Cloud style business services.

The code diff shows new template areas under sky/springcloud and sky/WEB-INF/springcloud, plus repeated changes in entity service classes, base service classes, request templates, schema generation, feature graph code, and validation support. This was a move from monolithic generated managers toward service-oriented generated infrastructure.

Business Foundation Templates​

The business-foundation templates covered generated service building blocks:

• base service
• entity service
• remote service implementation
• service adapter
• base request
• request DSL output
• generated POJO imports and members

The generator was extracting common backend behavior into reusable service infrastructure.

Entity Service Layer​

The entity service work added generated CRUD and lookup behavior:

• id and type lookup
• updater support
• entity service methods
• user context resolution
• criteria parameter preparation
• enum constants

This stage made generated services more explicit. Instead of all behavior living in manager templates, service templates could expose stable runtime contracts.

Schema and Validation​

The Spring Cloud branch also brought table schema generation and validation improvements.

That pairing is important: generated services need generated persistence contracts, and generated persistence contracts need generated validation. Keeping those in the generator reduces mismatch between API, schema, and domain rules.

Why This Stage Mattered​

The generator became less tied to a single Java web application shape.

Spring Cloud templates let the same model produce service infrastructure, request objects, remote service contracts, and schema metadata. This set up the later Request DSL and query API work by giving generated backend code a clearer service boundary.

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 2020, mobile generation became a first-class backend and frontend concern.

The code changes touched Taro templates, mobile backend service templates, WeChat app service templates, IAM service templates, display mode helpers, tree services, generated view pages, and React view groups. The generator was learning to emit an app that could run across web admin and mobile-miniapp channels.

Taro and Mobile App Templates​

The Taro templates introduced a generated mobile frontend target:

• app entry generation
• service center generation
• mobile object pages
• image and image-list support
• generated app path handling

The templates also guarded generation based on model features, so mobile code was emitted only when the domain model declared the right capability.

Mobile Backend Service Layer​

Mobile UI generation required backend support, so the Java templates added:

• mobile app backend tasks
• miniapp service view pages
• list and detail service methods
• display mode detection
• generated view-home-page behavior

This kept the mobile app from becoming a separate manual project. The backend view layer and frontend app layer evolved together.

IAM Generation​

The generator added IAM-related service templates:

• base IAM service
• WeChat mini-program handler
• WeChat mobile handler
• login method support
• key-pair verification
• avatar and phone update flows

Authentication and identity handling were becoming part of the generated application contract, not an afterthought bolted onto each project.

Tree and View Group Support​

The generated UI also gained tree services and view group customization.

That made navigation and object presentation more model-aware. The generator could produce different views for different user entry points while keeping the same domain backend underneath.

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.

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.

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.

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.

After the Java backend templates stabilized, the generator began producing client-side code.

The code diff shows new Android framework templates, Swift POJO templates, SwiftyJSON mapping helpers, remote manager templates, and sample HTTP request generation. This was not just adding another output language. It changed the generator from a backend scaffold into a multi-target system.

Android Application Skeleton​

The Android templates introduced generated application structure:

• activity framework files
• entry page fragments
• manifest templates
• generated string resources
• menu and naming convention helpers

The generated Android app did not need every screen to be handwritten. The same domain model could drive initial navigation, labels, and object entry pages.

Swift Object Generation​

Swift support added another important boundary: generated domain objects could exist outside Java.

The Swift templates produced:

• struct-based model objects
• custom string conversion
• JSON object mapping
• reference-list handling
• nil-safe member access

That forced the metadata layer to become less Java-specific. Field names, reference names, and type mapping had to work across languages.

Remote Manager Pattern​

The remote manager templates connected mobile clients back to generated backend services.

Instead of treating the mobile app as a separate hand-coded consumer, the generator began producing both sides of the contract: server manager methods and client access code. That reduced drift between API shape and client expectations.

Why This Stage Mattered​

The practical feature was mobile scaffolding. The architectural feature was bigger: one domain model could emit multiple runtime surfaces.

That idea later became essential for generating backend APIs, admin UI, mini-program code, search DSLs, and typed query APIs from the same model vocabulary.

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.

The first useful shape of the generator was not a UI scaffold. It was a persistence scaffold.

Looking at the code changes, the core work concentrated around FieldDescriptor, ObjectDescriptor, CMRField, Java POJO templates, JDBC mapper templates, DAO implementations, SQL templates, and manager methods. That tells a clear story: the generator was learning to convert a domain description into an executable Java data layer.

Generated Java Object Model​

The object templates started to produce more than plain fields:

• typed Java members from model fields
• constants for field names and table columns
• generated toString, JSON serialization, and null-safe formatting
• parent references and child reference lists
• version fields for optimistic updates

The important shift was that the generated entity became a stable contract. DAO, mapper, manager, serializer, and JSP snippets could all depend on the same metadata.

DAO, Mapper, and Manager Layers​

The generator added separate templates for:

• DAO interface
• JDBC template implementation
• row mapper
• load and save helpers
• manager interface
• manager implementation
• manager exceptions

This separation mattered because it made generated code patchable by layer. SQL mapping problems could be fixed in mapper templates. Business entry points could evolve in manager templates. Persistence behavior could change without rewriting the domain model.

Multi-Database SQL Output​

The early templates included MySQL, then added MSSQL support. Even at this stage, SQL was treated as generated infrastructure, not handwritten project code.

That design became a recurring theme: database differences should live behind generator templates and runtime helpers, while application code talks to generated typed APIs.

Relationship Handling​

The generator also started handling parent and child relationships:

• loading referenced objects
• saving object graphs without duplicating unchanged rows
• ordering fields deterministically
• producing mapper code for references

This was the beginning of TeaQL's later object-graph save model. The early code was still template-heavy, but the direction was already visible: describe the domain once, then generate the repetitive persistence surface.