1. Le module

Un module Kewos déclare. Il ne construit pas d’écran, ne dessine pas de formulaire, n’écrit pas de SQL.

Déclarer un modèle donne, sans une ligne de plus : la table, l’API, les écrans, la recherche, l’audit, les permissions, la traduction et l’export. L’administration découvre tout auprès du serveur, donc ajouter un module ne demande jamais de redéployer l’interface.

Le squelette

Un module est un dossier sous modules/. Le nôtre s’appelle library.

Python

modules/library/
├── module.json                <- identity and dependencies
├── __init__.py                  <- the entry point the kernel calls
├── icon.svg                     <- the launcher icon
├── acl.json                     <- the permissions
├── models/
│   ├── __init__.py
│   ├── title.py                 <- the work
│   ├── copy.py                  <- the physical copy
│   ├── member.py                <- the member
│   ├── loan.py                  <- the loan
│   └── workflow.py              <- the loan lifecycle
├── reports/                     <- the PDF documents
├── views/                       <- fourteen screens, in JSON
└── i18n/
    ├── en.json
    └── fr.json

YAML

modules/library/
├── manifest.yaml                <- identity and dependencies
├── icon.svg                     <- the launcher icon
├── security.yaml                <- groups, permissions, record and field rules
├── models/
│   ├── library_title.yaml       <- the work
│   ├── library_copy.yaml        <- the physical copy
│   ├── library_member.yaml      <- the member
│   └── library_loan.yaml        <- the loan
├── automation/
│   └── workflows.yaml           <- the loan lifecycle
├── views/                       <- one file per model, all its screens inside
└── i18n/
    ├── en.yaml
    └── fr.yaml

Pas de point d’entrée : il n’y a rien à appeler. Le noyau lit les fichiers.

KM

modules/library/
└── library.km                   <- tout le module, dans un fichier

C’est l’argument principal de KM face au YAML. Le même module, la même arborescence en moins : ce que huit fichiers décrivent se lit ici de haut en bas.

Les fichiers apparaissent au fil des étapes. Créez pour l’instant le dossier, le manifeste et le point d’entrée.

Le manifeste

Python

module.json :

{
  "name": "library",
  "depends": ["core"],
  "summary": "Library management: catalogue, copies, members and loans.",
  "version": "0.1.0",
  "category": "operations"
}

YAML

manifest.yaml, avec une clé de plus :

name: library
kind: declarative
version: 0.1.0
depends: [core]
category: operations
summary: "Library management: catalogue, copies, members and loans."

kind: declarative est ce qui dit au noyau de lire le dossier au lieu de l’importer. C’est la seule différence d’identité entre les deux formats.

KM

En tête de library.km :

module library {
  title   "Library"
  version 0.1.0
  depends core
}

Pas de kind : l’extension .km le dit déjà. Le noyau lit ce bloc, en fait le même manifeste que le YAML ci-contre, et remet le tout au même chargeur.

Clé	Rôle
name	Le nom technique. Il préfixe toutes vos tables.
depends	Les modules dont le vôtre a besoin. core au minimum.
version	Une version sémantique. Elle sert aux mises à jour et aux migrations.
category	Le rayon du lanceur : sales, assets, operations, hr, finance…
summary	Une phrase, affichée dans la liste des modules.

Le nom des tables n’est pas libre

Le préfixe d’une table est le nom du module : library_title, library_loan. Jamais un nom repris d’un autre progiciel, jamais res_* ni ir_*.

Ce n’est pas une préférence esthétique. Un nom emprunté à un concurrent crée une fausse familiarité : on suppose que le champ se comporte comme là-bas, et il ne le fait pas.

Le point d’entrée

Python

__init__.py, à la racine du module, expose la fonction que le noyau appelle au démarrage.

"""``library`` -- catalogue, copies, members and loans."""

from __future__ import annotations

from pathlib import Path
from typing import TYPE_CHECKING

from kewos.orm import apply_module_acls
from kewos.pdf import register_reports_from_dir
from kewos.views import register_views_from_dir

from . import models

if TYPE_CHECKING:
    from kewos.orm.registry import Registry

_MODULE_DIR = Path(__file__).parent


def register(registry: Registry) -> None:
    """Declare the module: models, permissions, screens, then documents."""
    models.register_models(registry)
    apply_module_acls(registry, _MODULE_DIR / "acl.json")
    register_views_from_dir(_MODULE_DIR / "views")
    register_reports_from_dir(_MODULE_DIR / "reports")

Quatre lignes, dans cet ordre : ce qui existe, qui y a droit, comment ça se montre, ce que ça imprime. C’est l’ordre de lecture d’un module Kewos, et il ne change jamais.

YAML

Il n’y en a pas.

Le chargeur découvre models/, views/, security.yaml, automation/ et i18n/ par leur nom, et appelle les mêmes fonctions du noyau que le module Python aurait appelées. C’est le principe du format : traduire, pas réinventer.

L’ordre est le même, il est simplement imposé par le chargeur au lieu d’être écrit par vous.

KM

Il n’y en a pas non plus, et pour la même raison : KM produit exactement les mêmes documents que le YAML, et c’est le chargeur déclaratif qui les applique.

L’ordre de lecture, lui, est celui de votre fichier : ce que vous écrivez en haut se lit en premier.

Un module n’importe jamais un autre module

from modules.sales import ... est interdit. Deux modules se parlent par événements et par registres, jamais par import direct.

C’est ce qui permet de retirer un module sans casser les autres, et de livrer un module à un client qui n’a pas les mêmes que vous.

Et ensuite

Les données : déclarer les quatre modèles.