| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
| Name | Name | Last commit date | ||
|---|---|---|---|---|
Seven complete Cordango applications, as source you can clone, read, change and build.
Status: pre-alpha. These track the App Definition schema in cordango/cordango and will move while it settles.
Each directory is a real workspace, not a snippet. What you see is what an author writes: one file per aggregate, an entity here, a lifecycle there, a role, a screen. No compiled App Definition is checked in, because that is the output of the toolchain rather than the thing a person edits.
cd expenses cordango check # parse, lower and validate. No model, no database. cordango inspect # what is in here cordango check --target standalone # can this be generated as an application you own? cordango build --target standalone --out generated --allow-incomplete cd generated && docker compose up --build
--allow-incomplete is needed today and says so out loud. The standalone generator does not yet emit workflows, computed fields or command guards, and rather than shipping an application that looks finished it refuses the build until you say you know. Every gap is listed in the generated README and recorded in cordango.build.json, so a partial build can never pass for a complete one later.
Then open http://localhost:8080: the first screen asks you to create the administrator account. There is no default password and none is generated for you.
The two marked Platform only are the exception: they reference the People core app for the personnel file, and a reference between applications is something only Cordango Platform can resolve. cordango check --target standalone refuses them outright rather than degrading, so they are read, checked and published rather than built and run locally.
docs.cordango.com — the quickstart, authoring, and the concepts these applications are written in.
| Example | Entities | What it shows |
|---|---|---|
| expenses/ | 1 | The smallest complete application, and the one to read first. An approval lifecycle, and three roles that see genuinely different things. |
| time-off/ | 1 | Absence requests with a manager approval step, a team schedule, and a duration the application works out for itself. |
| task-manager/ | 5 | Projects, tasks, subtasks and milestones, with rollups that let a parent count its children. Read this one for computed fields. |
| room-booking/ | 4 | Rooms, bookings, attendees, and a policy entity that holds the rules instead of hard-coding them. |
| budget-planner/ | 16 | The largest by a distance, and the one that pushes the language hardest: scenarios, cohort growth, rollups across a window, and a running cash balance that reads the row before it. Read it for the calculation plane. |
| time-records/ | 10 | Working time under German law — the recording every employer has owed since the Bundesarbeitsgericht decided it in 2022. Rules that are given from outside and cannot be argued with: a step function built without a branch, an eleven-hour rest read from the previous day, and a works-council role that the entity shapes make possible. Platform only. |
| time-and-leave/ | 16 | The same application plus holiday, sickness and a Gleitzeit account. Contracted hours joined by weekday through a one-value window, and a balance that carries itself from month to month. Platform only. |
Start with apps/<name>/app.cordango.yaml, which names the application and fixes the order things appear in. Then:
entities/ what the application stores, one file per entity workflows/ lifecycles (a record's states and the moves between them) and automations roles/ who may read, write and run what views/collections/ a table, board or calendar over one entity views/screens/ a page, assembled from views and blocks views/entities/ one record's detail, peek and form
An improvement here reaches everyone using the example, in either environment. Clearer labels, more realistic permissions, a state a lifecycle is missing, a screen that reads better: all welcome.
Two things to check before opening a pull request:
cordango check --app <name> cordango check --app <name> --target standalone
The first asks whether it is a valid Cordango application. The second asks the narrower question of whether the standalone generator can also build it. A standalone build is one application, so anything that depends on other installed applications is reported rather than silently dropped.
Each was imported from the conformance corpus in the compiler repository using cordango import, which turns an App Definition back into source. That corpus stays where it is, because the test suite is pinned to it and it must not drift. These copies are the ones meant for people to read, and they are allowed to grow.
Apache-2.0. See LICENSE.
| Back | FazBrowse Home | New Git URL |