- Lua 97.7%
- Shell 1.6%
- Makefile 0.7%
| .github | ||
| config | ||
| docs | ||
| scanner | ||
| scripts | ||
| test | ||
| .fragjan | ||
| .gitignore | ||
| .merkwerk | ||
| .version_history | ||
| composer.lua | ||
| init.lua | ||
| lang.lua | ||
| LICENSE | ||
| loader.lua | ||
| Makefile | ||
| README.md | ||
| types.lua | ||
| VERSION | ||
daw-modul-berhtjan-core
Composer and field type registry for berhtjan UI contributions.
daw-modul-berhtjan-core loads, validates and composes contribution.json
declarations from Dragons@Work modules, and resolves field types against
the daw_field_type/v1 contract -- no field type name is hardcoded in
Core itself, not even a "primitive" one.
Status: In development · Lua: 5.1 / 5.4 · License: ISC
❤️ Contribute and support our work
What is daw-modul-berhtjan-core?
daw-modul-berhtjan-core is the foundation of the berhtjan UI layer in
the Dragons@Work ecosystem. It knows no concrete field types itself --
not text, not number, not any name at all. Instead it structurally
validates field type definitions against the open
daw_field_type/v1
contract and resolves them at runtime from a registry that modules and
host programs populate.
Renderers (CLI, web, desktop, API) receive fully composed field
definitions from berhtjan-core and decide themselves how to present a
given value.kind/acquisition combination.
What problem does it solve?
berhtjan-core originally hardcoded six field types directly in code
(text, textarea, number, boolean, select, date). A new
field type meant a code change to Core -- and usually to every
renderer that needed to display it.
With daw_field_type/v1, a new field type is pure data: value
semantics (value.kind, open vocabulary) are separated from
acquisition paths (direct, selection, resource). A module can
introduce a completely new field type without Core or an existing
renderer being touched -- as long as the type is built from the known
acquisition mechanisms.
Status
- In active development, Lua 5.1 and 5.4 supported
- Fully migrated to
daw_error/v1(structured error objects instead of error strings) anddaw_field_type/v1(field type registry instead of hardcoded primitives) - Known open questions: where the ecosystem's base field types are
shipped from as data,
constraintvocabulary keys are closed but minimal (seedaw-contracts)
Installation
daw-modul-berhtjan-core is included as a git dependency, not installed via a package manager:
git clone https://smida.dragons-at-work.de/DAW/daw-modul-berhtjan-core.git \
lib/daw/berhtjan_core
Usage
local core = require("daw.berhtjan_core")
-- parse a contribution and its type definitions
local contrib, err = core.parse_contribution(raw_json)
local types, err2 = core.parse_types(raw_types_json) -- validated against daw_field_type/v1
local registry, err3 = core.merge_types({ types_a, types_b })
-- compose for a host (nil = all groups)
local composed, err4 = core.compose(contrib, registry, { "core", "prices" })
-- resolve a single field type
local def, err5 = core.resolve_type("text", registry)
-- resolve language/label -- no silent fallback, a missing label is an error
local lang, err6 = core.resolve_lang(ctx)
local label, err7 = core.resolve_label(field.label, lang, ctx.default_lang)
Every public function follows the
daw_error/v1
contract: value, nil | nil, daw_error/v1 -- never a raw error string.
Documentation
daw_error/v1-- error contractdaw_field_type/v1-- field type contract
Development and Testing
Requirements: Lua 5.1 or 5.4, daw-lua-common.
git clone https://smida.dragons-at-work.de/DAW/daw-modul-berhtjan-core.git
cd daw-modul-berhtjan-core
git clone https://smida.dragons-at-work.de/DAW/daw-lua-common.git lib/daw/common
make test
echo "DAW_LUA_VERSION = 5.1" > config/local.mk && make test # check against Lua 5.1
Contributing
Bug reports, tests, feedback, and contributions are welcome.
The primary development repository is on Forgejo: Development repository
The GitHub repository is a public mirror for better discoverability. Please submit issues and contributions to the primary repository.
Open Knowledge Needs People
We develop ideas, share knowledge, and build open source software and tools. Projects like this one don't grow on their own -- they live because people ask questions, experiment, share knowledge, find bugs, and help make things better.
You can contribute in different ways:
- reporting bugs
- reviewing code
- testing on other platforms
- improving documentation
- translating content
- or, if you like, supporting us financially
Every contribution helps us keep developing open knowledge and open source software.
Contribute and support our work →
License
Released under the ISC License as part of the Dragons@Work open source ecosystem.