Modellieren im Hub

Worum es geht

Bevor es Code gibt, gibt es ein Modell. Du beschreibst im Hub, welche Dinge deine Anwendung kennt (Kunde, Auftrag, Rechnung), welche Felder sie haben, wie sie zusammenhängen und wer was darf. Aus dieser Beschreibung erzeugt der Build später den ganzen Code, siehe Codegenerierung im Build.

Du modellierst also, du programmierst hier nicht. Alles, was du festlegst, sind Daten im Hub: die Metadaten deiner Anwendung.

Das Meta-Modell

So hängen die Dinge zusammen, die du im Hub anlegst:

flowchart TD
    P["Projekt"] --> S["System<br/>(eine CDMS-Anwendung)"]
    S --> F["Ordner"]
    S --> E["Enumeration"]
    S --> M["Modell"]
    F -. "enthält" .-> M
    F -. "enthält" .-> E
    E --> EI["Enum-Wert"]
    M --> FD["Feld"]
    M --> EP["Endpunkt"]
    M --> R["Rolle"]
    M --> AF["Zugriffsfilter"]
    M --> H["Hook"]
    M -. "erbt von" .-> AM["abstraktes Modell"]
    FD --> RU["Regel"]
    FD --> FR["Feldrolle"]
    FD -. "Enum-Feld" .-> E
    FD -. "Beziehungsfeld" .-> M

Drei Arten von Modellen

Ein Modell kann nur von einem abstrakten Modell erben. Mehr dazu unter Abstrakte Modelle, Singleton und Das Datei-Modell.

Zu jedem Modell legst du außerdem fest:

Felder

Jedes Feld ist eine von drei Arten:

Eine Beziehung ist im Hub immer ein Feldpaar. Legst du an Order das Feld customer (MANY_TO_ONE auf Customer) an, entsteht an Customer das Gegenfeld mit der umgekehrten Art (ONE_TO_MANY). Beide werden in einer Transaktion gespeichert. Löschst du eine Seite, löscht der Hub die andere mit.

Manche Felder legst du nie selbst an, weil jedes Modell sie schon hat: id, _createdOn, _updatedOn und je nach Ebene _userId. Siehe Systemfelder.

Regeln am Feld

Regeln sagen, welche Werte ein Feld annehmen darf. CDMS prüft sie beim Schreiben, siehe Validierung.

Die Höchstlänge eines Textes ist keine Regel, sondern die Eigenschaft Länge des Feldes.

Einige Regeln kannst du auf einen Geltungsbereich beschränken: ALWAYS (Standard), nur CREATE oder nur UPDATE. Das geht bei „nicht leer“, „Muster“ und „Mindest-/Höchstwert“. Beim Pflichtfeld steckt die Operation schon in der Regel selbst.

Endpunkte und Rechte

Im Reiter Endpunkte legst du fest, welche Operationen es für das Modell gibt. Die Oberfläche bietet immer die fünf Grundoperationen an (CREATE, READ, UPDATE, DELETE, LIST). Die Historie-Endpunkte gibt es nur bei auditierten Modellen, UPLOAD und DOWNLOAD nur bei Datei-Modellen. Was welcher Typ im Code erzeugt, steht unter Welche Endpunkte ein Modell hat.

Im Reiter Berechtigungen markierst du, welche Operationen eine eigene Rolle verlangen. Du setzt dabei nur einen Haken je Operation. Den Rollennamen bildet der Generator nach einem festen Schema aus Ordner, Modell und Operation. Genauso gibt es Feldrollen am einzelnen Feld. Siehe Modellrollen, Feldrollen und Rollennamen.

Im Reiter Filter verbindest du ein Profilattribut des Benutzers mit einem Feld. Dann sieht jeder nur die Zeilen, deren Feld zu seinem Attribut passt, siehe Attributfilter.

Welche Regeln der Hub durchsetzt

Beim Speichern prüft der Hub deine Eingaben. Ein Verstoß wird abgelehnt, und die Oberfläche zeigt dir den Grund am Feld.

Den Pfad eines Ordners berechnet der Hub selbst. Benennst du einen Ordner um oder verschiebst ihn, passt er die Pfade des ganzen Teilbaums an.

Manche Dinge sind erlaubt, aber meistens ein Versehen. Dafür zeigt die Oberfläche am Feld ein Warnzeichen:

Checkliste: ein neues Modell

Statt von Hand kann auch ein KI-Client das Modell ändern, über den MCP-Server des Hubs.

Fallen