Documentation
Four kinds of documentation, in the order a team usually needs them: what the framework is, what an application built on it does, how you model that application, and the Java it runs on.
Start here
Framework Overview: the components, the server stack, the technologies and the concepts the rest of the documentation assumes.
Getting Started: installation, IDE setup and a sample project worked through from an empty directory.
What an application does
Features: one page per feature, from entity rules and temporal records to grids, toolbars, tenants and saved filters. Each page shows the declaration that turns the feature on, the behaviour that follows, and where the feature stops.
Modelling an application
The Werc DSL is where an application is declared. Both references follow the grammar, keyword by keyword.
Server DSL: value types, entities, fields, relations, queries and view models.
Client DSL: grids, forms, toolbars, pages and actions.
The Java underneath
Domain Library: the value types and the entity contract every application is built from, and what the framework does with them.
Framework Aspects: the patterns that recur across applications, such as documents and their lines, entity status and posted finance.
API reference: the generated javadoc of the published API, package by package. Packages named
internalcarry no compatibility promise and are left out of it.
How this documentation is produced
The manuals are written by hand in the framework’s own source tree and published from it, so a page and the code it describes travel together. The feature pages are written beside the design each feature came from. Package level API documentation in the javadoc is written with AI assistance against the source and verified by the build.