KoratModule sind Korats Antwort auf das Problem, eine App für Restaurants, Hotels, Praxen und Läden zu bauen: Die ehrliche Fassung davon sind vier Apps mit gemeinsamem Login. Die unehrliche ist eine App mit einem Einstellungsbildschirm, der so groß ist, dass jeder Betrieb überwiegend Dinge sieht, die ihn nicht betreffen. Korat geht einen dritten Weg: Der Betriebstyp wählt ein Modul, das Modul baut die Oberfläche, und weder die öffentliche Seite noch die Konsole wissen fest verdrahtet, was ein Restaurant ist.
Der Modulvertrag
Ein Modul erklärt einen festen Satz von Dingen, und die App setzt alles Übrige daraus zusammen. Es nennt eine Id; die beanspruchten Betriebstypen, die entscheiden, ob das Modul für einen Laden gilt; eine Bezeichnung und einen Katalogtitel; eine primäre Handlungsaufforderung, den einen Knopf, mit dem die Kundenseite führt; und eine Katalogansicht — eine Speisekarte für Food, Zimmertypen für Stay, Leistungen für eine Praxis, Produkte für Retail.
Vier weitere Angaben sind optional, und dort verdient das System sein Geld. Ein Modul kann Berechtigungen erklären, die zu neuen Rechten für Rollen werden; Konsolenkacheln, die im Kachelraster erscheinen; einen eigenen Konsolenbildschirm; und einen Abschnitt auf der Kundenseite, der in die öffentliche Seite eingesetzt wird. Ein Modul ohne diese vier ist ein reiner Katalog; eines mit allen vier formt beide Seiten der App zugleich um.
Dazu gibt es einen gemeinsamen UI-Baukasten — Hauptknopf, Katalogzeile, Chip, Abschnittsbeschriftung und Leerzustand —, aus dem Module bauen sollen. Nicht Hausstil um seiner selbst willen: Er ist der Grund, warum ein separat geschriebenes Modul wie ein Teil der App aussieht und nicht wie ein eingebettetes Widget.
Die vier Kernmodule sind die Betriebstypen
Die vier Kernmodule sind gar keine Erweiterungen; sie sind das, was ein Betriebstyp bedeutet. Food beansprucht Restaurant und Café. Stay beansprucht Unterkunft, Hotel, Resort, Apartment, Eigentumswohnung und Wohnanlage — sechs Bezeichnungen, ein Modul, weil eine Monatsmiete und eine Pensionsnacht sich im Wort unterscheiden, nicht im Mechanismus. Service beansprucht Service und Praxis, wobei die Praxisvariante die Oberfläche in Termine, Patienten und Behandlungsserien umbenennt, ohne den Code zu spalten. Retail beansprucht Handel.
Weil das Module sind und keine Verzweigungen in einem Riesenbildschirm, existieren Küchenanzeige und Optionsgruppen des Food-Moduls für ein Hotel nicht — nicht hinter einem Schalter versteckt, nicht deaktiviert, sondern abwesend. Was ein Laden zu sehen bekommt, ist eine Funktion dessen, wozu er sich erklärt hat.
Vier installierbare Erweiterungen, für jeden Typ
Über den Kernmodulen liegen sieben Erweiterungen, die unabhängig vom Betriebstyp gelten. Teamrechte ist die interessanteste, weil sie aus den anderen Modulen gebaut wird: Sie konstruiert einen Rechteeditor aus den erklärten Berechtigungen aller installierten Module — ein neues Modul bringt seine Rechte also in den Editor, ohne dass jemand eine Liste pflegt. Dieselben Berechtigungen liest später has_capability() in der Datenbank, beschrieben auf der Sicherheitsseite.
Zahlungswege ergänzt eine Konsolenkachel zur Pflege der akzeptierten Wege und eine für Kundschaft sichtbare Liste auf der öffentlichen Seite — eine Erweiterung, die über zwei Vertragsschlitze auf beide Seiten schreibt. Mitgliedschaften und Abos führt Tarife ein, die Kundschaft direkt auf der Ladenseite kauft. Verlängerungserinnerungen übernimmt die Nachfassarbeit, die Mitgliedschaften und Serien erzeugen. Jede ist ein ausgeliefertes eigenes Modul, geschrieben gegen denselben Vertrag, den Dritte nutzen würden — eine bewusste Disziplin, denn ein Vertrag ist nur echt, wenn auch seine Autoren daran gebunden sind.
Installieren und Deinstallieren, je Laden
Erweiterungen werden aus dem Plugin-Store in der Konsole verwaltet, und die Installation gilt für genau einen Betrieb. Wer zwei Läden führt, kann Mitgliedschaften in einem installieren und im anderen nicht — die beiden Übersichten unterscheiden sich dann wirklich.
Das Deinstallieren steht hinter einer Rückfrage, und die sagt etwas Bestimmtes: Die Daten werden nicht gelöscht. Das ist wichtiger, als es klingt. Menschen zögern vor einem Deinstallieren-Knopf, weil sie ihn für zerstörend halten — also lassen sie Module installiert, die sie nicht nutzen, und die Konsole füllt sich mit Kacheln, die niemand öffnet. Zu sagen, was *nicht* passiert, macht den Knopf erst benutzbar. Nach dem Deinstallieren steuert die Erweiterung nichts mehr bei — keine Kacheln, keine Rechte im Rolleneditor, keinen Abschnitt auf der öffentlichen Seite —, aber ihre Datensätze überstehen eine Neuinstallation.
Was das noch nicht ist
Plugins von Dritten sind nicht offen. Der Plugin-Store sagt das selbst, statt es über ein leeres Regal mit „mehr in Kürze“ anzudeuten. Heute existiert eine modulare Architektur mit einem echten Vertrag, vier Kernmodulen und vier eigenen Erweiterungen dagegen geschrieben, alle über denselben Registrierungsweg geladen. Die Einreichung durch Dritte ist der erklärte nächste Schritt, kein laufender Marktplatz: Es gibt kein Entwicklerportal, keine Prüfschlange und kein veröffentlichtes SDK.
Wir beschreiben es so, weil die Architektur der interessante Teil ist und heute zutrifft, während ein Marktplatz eine Behauptung über die Zukunft wäre. Der Test des Vertrags ist, ob ein vollständig gegen ihn geschriebenes Modul — Kacheln, Berechtigungen und ein Seitenabschnitt, ohne Kerncode anzufassen — sich wie ein nativer Teil der App verhält. Vier tun das. Das für Außenstehende zu öffnen ist eher ein Richtlinien- und Prüfproblem als ein technisches, und es ist nicht gelöst.
Warum Module statt Feature-Schalter
Ein Feature-Schalter schaltet etwas ab. Ein Modul steuert etwas bei. Der Unterschied zeigt sich im Rechteeditor: Mit Schaltern pflegt jemand eine Hauptliste aller Berechtigungen und muss daran denken, sie zu erweitern. Mit dem Vertrag fragt die Erweiterung Teamrechte jedes installierte Modul, was es erklärt, und baut den Editor aus den Antworten — die Liste kann also nicht veralten. Dasselbe Muster gilt für das Kachelraster und die öffentliche Seite: Keines zählt Funktionen auf, alle fragen.
Es begrenzt außerdem die Kosten einer neuen Branche. Einen Betriebstyp zu ergänzen, den Korat noch nicht bedient, ist ein Modul: die beanspruchten Typen erklären, einen Katalog, eine Handlungsaufforderung und die optionalen Schlitze, die es braucht — ohne Konsole, Seitenrenderer oder Rechtesystem anzufassen. Das macht eine Super-App handhabbar statt zu einer langsamen Ansammlung von Sonderfällen.
Es gibt keinen Marktplatz für Plugins von Dritten. Alles heute Installierbare stammt aus dem Projekt selbst, und der Store sagt das in der App. Die Einreichung durch Dritte ist der erklärte nächste Schritt — ein Entwicklerportal und ein veröffentlichtes SDK gibt es noch nicht.
Außerdem liegt der Plugin-Code weiterhin im APK, statt bei Bedarf je Plugin geladen zu werden. Das ist eine bekannte Einschränkung und die offensichtliche Voraussetzung dafür, den Store für Leute außerhalb des Projekts zu öffnen.
- Pflichtangaben
- Id · beanspruchte Betriebstypen · Bezeichnung · Katalogtitel · primäre Handlungsaufforderung · Katalogansicht
- Optionale Angaben
- Berechtigungen · Konsolenkacheln · Konsolenbildschirm · Abschnitt auf der Kundenseite
- Kernmodule
- Food · Stay · Service · Retail
- Erweiterungen
- Teamrechte · Zahlungswege · Mitgliedschaften und Abos · Verlängerungserinnerungen
- Installationsbereich
- je Laden
- Deinstallieren
- hinter einer Rückfrage, die sagt, dass Daten nicht gelöscht werden
- Dritte
- nicht offen — nur eigene Erweiterungen