OrgaMon-next

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
  • Dies ist die Konzept-Sammlung für die nächste Version des OrgaMon "OrgaMon Polyzalos"
  • OrgaMon setzt wo immer möglich die Programmiersprache "Object-Pascal", auch bei Dingen die in Wirklichkeit als "JavaScript" im Browser des Anwenders laufen (CrossCompile).
  • Als Compiler wird nur noch Free-Pascal eingesetzt, Wegfall von "Delphi"
  • Es werden nur noch Open-Source Komponenten eingesetzt
  • Die mit der Delphi-IDE erstellte UI entfällt, der cOrgaMon übernimmt die Funktion eines WebServers
  • dazu ist das HTTP2-Projekt ein wesentlicher Anteil von OrgaMon Polyzalos
  • cOrgaMon wird vorrangig auf Linux Maschinen installiert, unter systemd als (Type=notify) mit "READY=1" nach lesen der ini
  • der eCommerce-Kernel soll Schritt für Schritt Kopplungspunkte bekommen wobei Kunden dann Anpassungen machen können. Das Customizing sollte aber auch wieder Open-Source sein und auch Test-Cases beinhalten so dass es für andere Kunden Regeressionsfrei bleibt.
  • Die Lazarus-IDE soll auch für Kunden eine Möglichkeit sein, auf den Code einfluss zu nehmen. Dabei soll die neue Paket-Verwaltung von Lazarus den OrgaMon mit wenigen Klicks "installieren" können

OrgaMon Polyzalos

Überblick

  • Polyzalos
  • Im Zentrum steht der FreePascal-Compiler der pro Projekt-Compilierung 2x den Code compilieren muss.
    • Erster Compiler Lauf: Compilierung nach cOrgaMon.exe, also ein http2 Server (Kern) mit Verarbeitungs-Code
    • Zweiter Compiler Lauf: Compilierung nach JavaScript und Auslieferung der veränderten Code-Anteile
  • Der Programmierer vermischt weiterhin UI-Code mit Anwendungs-Code, in Wirklichkeit
    • verteilt der Compiler den Code auf den Server (NON-UI-Anteile) und ausserdem auf den Browser-Client (UI-Anteile, und triviale Berechnungen, Eingabeprüfung)
    • dabei werden Objekt-Methoden angewandt, die ggf. auf dem Client oder dem Server laufen oder beides
    • ggf. sind Methoden auf dem Client nicht ausführbar und erfordern Aktionen auf dem Server, dies erfolgt grundsätzlich "nonblocking", also der Client wartet nie, sondern setzt nur Requests ab

Workflow

  • Pure Pascal Prinzip
    • Das DOM-Modell wird per Pascal-Objekt abstrahiert, es soll kein writeln('-b-fett-/b-'); geben
    • Die Tatsache HTML5/CSS/JavaScript wird völlig verborgen, für den Programmierer ist ALLES Pascal
    • Auf dem Client lauffähiger Code wird zu JavaScript
    • Auf dem Server lauffähiger Code wird zu nativem Plattform-Binary
    • Der Sync der Variablen / Datenbank darf nicht die UI blockieren
    • Abbruch der Verbindung zum Server darf nie ein Problem sein
    • die Server-Worker und Client-Worker müssen transaktionsgesteuert und reconnect fähig sein

Asynchron

  • eine Polyzalos Anwendung läuft im Browser blockiert aber niemals um eine Antwort auf einen Server-Request zu erhalten
    • Anfragen und Calls an den Server werden in eine lokale SQLite3 Datenbank geschrieben (SQLite3 in der Webassembly-Version im Browser, nativ auf dem Server)
    • Ein Worker versucht Antworten vom Server zu erhalten
    • Ein Worker füllt zum passenden Request die Datenbank mit Ergebnisdaten des Servers
    • Der Worker ruft Callbacks des UI-OS um das jeweilige DOM von z.B. "unsaved, =gelb" auf "saved, weiß" zu stellen

WVCL-OS

  • eine Polyzalos-Anwendung benutzt im Web eine API zu einem statischen css+html+JavaScript Monolith Web-Visual-Component-Library-Operating-System (WVCL-OS)
    • UI-OS ist ein Unterprojekt von Lazarus und soll langfristig auch die IDE ins Web bringen können
    • UI-OS wird eher durch Web-Leute gepflegt und weiterentwickelt und per JavaScript von der Polyzalos Anwendung gerufen
    • Wird UI-OS einmal inkompatibel mit "alten" Polyzalos Anwendungen müssen moderne Anwendungen in eine bestimmte UI-OS Version hochschalten

Formulardesigner

  • Migrations-Phase: Aus der Delphi Code-Basis werden alle dfm nach lfm übernommen (132 Formulare!)
  • Das Design/Redesign/Neudesign von Formularen erfolgt ab dann in der Lazarus IDE
  • Ein grober Funktionstest kann so ohne Web, mit dem Lazarus-Compilier-Ziel LCL (native GUI-Anwendung) gemacht werden
    • dies wird wohl nicht für immer und ewig unterstützt, da der User genau wissen muss welche Komponenten er überhaupt verwenden kann, es wird nicht alles unterstüzt
    • Zumindest solange bis Chrome unzulänglich als compile Target in Lazarus intergriert ist
    • Im Endausbau soll Lazarus nativ in ein Chromefenster compilieren, ev. gibt es auch mal einen lfm Designer fürs Web
  • die lfm werden zum Client übertragen der sie in einer Offline-Datenhaltung speichert (Versioning der lfm-Files!)
  • der Client erzeugt aus den lfm eine wfm (HTML5-DOM) die entsprechend das Aussehen des lcl-Formulares nur grob imitiert aber
    • wfm ist nicht mehr pixelgenau
    • wfm baut massiv auf der Tab-Order auf, das ist die Vorgabe für das "Verständnis" der UI
    • wfm ist reactive
    • der Client hat ein WCL (JavaScript-Kernel) welcher TButton, TListbox, TLabel kennt, das gehört zum Client-Kernel

Bildliche Assoziation

Systemvergleich

Turbo Pascal 1989

  • Der Compiler erzeugt Assemblercode für die x86 Plattform und hat dabei
    • Knowhow über den Umgang mit Heap- und Hauptspeicher
    • Knowhow über elementare Betriebssystemaufrufe für writeln, readln, AssignFile, ...
  • Es wird linearer Code für das Zielsystem DOS erstellt und gestartet

Delphi

  • Es wird an eine MessageLoop des Betriebssystems angedockt und so
    • Click- und Mausevents verarbeitet
    • Signale für die GUI verabeitet (close-Window, refresh Window usw.)
  • Es wird ein Single-Thread-Code für das Zielsystem WIN erstellt und gestartet
  • Formulare (GUI), es werden Objekte über deren Namen und Objekt-Eigenschaften als Text-Dateien gespeichert (*.dfm)

FreePascal Polyzalos

  • Erstmals werden 2 Compilate erstellt: der Code für UI und der Code für den Server
  • Dies erfolgt durch 2-maliges Compilieren der selben Code-Basis
  • Server-Code ist nah am Zielbetriebssystem mit nativem Assembler Code und OS-Nutzung (klassischer IDE-Betrieb)
  • Client-Code ist erzeugtes JavaScript zusammen mit statischem Content in html5, dem JavaScript steht eine Client-OS-Infrastruktur in Form von einer rtl.js zur Verfügung


  • typische Server-Funktionen
    • eine Verbindung zu firebird
    • Erstellen und Verarbeiten von Dateien im Dateisystem
    • Uploads- Downloads von/auf anderen Servern
    • Hosten der index.html (minimales starres Template, unveränderlich über alle Projekte hinweg)
    • Hosten des Polyzalos Compilates (.js)
    • Hosten der "RTL" (.js)
  • typische Client-Funktionen
    • wird ein Button gedrückt so werden zunächst andere Controls disabled und eine Server-Anforderung gestellt
    • wird eine Drop-Down-Box gedrückt wird eine Liste angefordert, ist eine Liste bereits gespeichert wird geprüft ob diese noch aktuell ist
    • Synchronisation von Server-Datenbank in eine lokale persistente Datenbank
    • Teil des Frameworks https://docs.emmet.io/cheat-sheet/ zur Hilfe bei html Erstellung

Code-Beispiel

bestehende Widgetsets

Hello World

program index;

uses
 p2020;

begin
 writeln('Hello World!');
end.

Slider

OrgaMon UI

User Interface (UI) Ideen

ein Projekt, das zum Ziel hat den OrgaMon mit einer Plattform-übergreifenden GUI anzubieten

farbige Tabs

  • Tab sind erst mal nicht da, können aber aus einem Suchbegriff oder einem Befehl frisch erzeugt werden. Wird z.B. ein Vertrag angewendet entstehen ev. ganz viele neue Beleg, ein Beleg wir als ein einzelner Tab angezeigt.
  • Standard-Aktionen sind auf Tabs anwendbar und können als transaktion auf Gruppen von TAbs angewendet werden.
  • Eine aktuell eingerichtete Tab-Gruppe (3 Personen und 2 Beleg und 1 Vertrag) kann in einer Tab-Historie gespeichert werden.
  • Tab-Favoriten gibt es auch, auf die "Umgeschaltet" werden kann aber auch "dazugeladen" werden kann.
  • man kann mehrere Belege öffnen und gleichzeitig bearbeiten. Dazu "Zieht" man sich einen neuen Tab. Tabs aus der selben Gruppe haben die gleiche Farbe und sind immer zusammen angeordnet (Gruppe schliessen).
  • Es gibt einen Neu Tab.
  • Ein Langer gehaltener Klick auf einen Tab erzeugt einen "Drag"-Event

Tab-Funktionen

  • Anklicken: Der Tab-Inhalt kommt nach vorne, jetzt erst wenn der TabInhalt sichtbar ist wird das kleine "close" sichtbar.
  • Schliesst man den Browser mit offenen Tabs muss am nächsten Tag ein reconnect erfolgen mit allen Inhalten parat!!!

Tabellen

  • Spaltenbreiten sollen gezogen werden können oder "auto"
  • Titel ^v wenn Hoch + Runter zu sehen ist, dann ist KEINE Sortierung aktiv
  • Titel v aufsteigende Sortierung
  • Titel ^ absteigende Sortiertung
  • Spaltenlayout soll auf "default" zurückgesetzt werden können
  • Spaltenlayout, wie es im Moment ist, soll gespeichert werden können
  • 1. Rang, 2. Rang: Idee : Ev. durch den vertikalen Abstand zur Tabelle den Rang symbolisieren, also je höher desto hochrangiger
  • Markieren sollte immer gleich funktionieren, "M" dann wird es blau ...

Progressbereich

  • zeigt zentral aktuelle Wartezeiten an, im Hilfehinweis oberhalb laufen Log meldungen
  • ich bin unsicher, ob dies durchführbar ist, aber ich will eine Unstoppable GUI die einfach nur Anforderungen an eine Exekutive weitergibt. In dem Progressbereich stapeln sich einfach Aufgaben, die im Moment am laufen sind und noch nicht abgeschlossen (Beispiele Dafür: Tagwache auf einem Server, Tagesabschluss auf einem Server, Anwendung von Verträgen usw.)

Suchbereich

  • OrgaMon ist (wieder) über Hotkeys steuerbar: <ctrl>PN macht "Person" "neu" der Focus steht beim Vornamen usw.
  • Kann man die oft in Anleitungen oder Bugreports verwendeten Bedienungsketten, also Eingaben benutzten?
  • Baustelle 🠖 Reiter "Verfügbar" 🠖 Haken bei [v] Senden 🠖 Button OK

SVG woimmer es geht

blauer Aqua-Button

der Start-knopf des OrgaMon, hier kommen die ganzen früheren Menü Möglichkeiten

ARIA Keyboard Support

UI Implementierung

  • 22.12.2016: Das Konzept des OrgaMon 9 steht:
  • GUI ist ...
  • immer ein Firefox-Client ab Rev. 50+ (KEINE AUSREDEN, KEIN EDGE, KEIN CHROME, einfach eine Blank Screen in dem Fall!! PUNKT)
  • immer https:// (HTTP/2)
    • immer window.isSecureContext
  • immer html5 und JavaScript, immer generiert aus eigenen Quellen, nach Möglichkeit keine Meta-Ebene auf dem Client, alles direkt und "nativ"
  • kein HTTPS Server dazwischen (z.B. Apache oder nxing)
  • eigene Session Verwaltung über die Datenbank
  • Die Bedienelemente sollen ganz einfach beginnen und dann Schritt für Schritt mächtiger werden
  • Als Icons sollen immer SVG Symbole verwendet werden
  • Ein erster Start könnte https://github.com/xtermjs/xterm.js sein
  • ag-grid könnte für data Grids eine gute Ersparniss sein
  • dabei soll mit Hilfe des Codes von Michael Van Canneyt JavaScript für den Client aus Pascal Programmierung erstellt werden, die JavaScript Tatsache soll versteckt bleiben

automatisierte Tests

Asynchrone UI

  • Also ein gedrückter Knopf bedeutet
    • sofortige Deaktivierung, das ist das Feedback für die Annahme des Auftrags des UI
    • die UI darf nicht blockieren, weitere Knöpfe sind weiterhin aktiv
    • folgender Status Feedback, dass der Request in die Datenbank eingetragen ist
    • folgender Status Feedback, dass der Request zum Server übertragen werden konnte (mit Offline-Zeiten ist hier zu rechnen, das darf kein Problem sein)
    • folgender Status Feedback, dass eine Antwort des Servers da ist mit neuem Status für diesen Button (Ein Erfolg, Ein Misserfolg, ein Fortschritt)

erste Schritte

  • ein Fenster mit einer Schaltfläche:

offene Fragen:

  • Wie das lokale Dateisystem angesprochen werden soll weiss ich noch nicht
  • Wie das Design der Fomulare erfolgen soll weiss ich noch nicht (also mit welcher IDE, XML Definitionen, ...) Formulare sollen jedoch in der Datenbank stehen
  • In einer Übergangsphase soll ein Webkit in den OrgaMon.exe integriert werden (der OrgaMon wird z.B. auch einen Magnetstreifen scannen müssen, oder Datensicherung machen, oder den Computernamen abfragen, oder?)
HTML5-
Client  <--https/2--> systemd Socket Activation <---sd_listen_fds()---> hOrgaMon Web Server    <--fbclient----> FirebirdSQL
                                                                        (links libsystemd.so)   +--file I/O---> .\OrgaMon\

Das User-Interface-Grundgesetz

Im Zentrum einer GUI müssen unverhandelbare Grundrechte des Benutzers / Bedieners stehen. Die Optik des UI muss klare Signale an den Benutzer senden so dass dieser sich 100% auf Funktionen des Interface verlassen kann. Auswüchse die es im Moment gibt (Wir sind immer noch in der IT-Steinzeit) müssen verhindert werden. Ich will für die Tatsache sensibilisieren das heute Webinhalte den User im Unklaren lassen was er auf einem Screen machen kann. Grafisch möglicherweise perfekt muss er erst mal mit der Maus rumsuchen was anklickbar ist. Wenn er dann anklickt kommt kein Feedback. Er muss nun hoffen dass sich was tut in den nächsten 5 Sekunden.

Negativ-Beispiele die vermieden werden sollen

  • Beispiel: Edge: Während man in der Adresszeile des Browsers ist wechselt der Eingabefokus in ein anderes Control
  • Beispiel: Bevormundung: Verschiedene Programme: Eine Eingabehilfe ergänzt die Eingaben "i" zu "intelligent". "i" <ENTER> ergibt also den Eingabewert "intelligent". Man muss "i" <BLANK> <BS> <ENTER> eingeben um einfach nur "i" zu erhalten, das darf nicht sein!
  • Beispiel: Delphi: Suchbegriffe werden immer vervollständigt, will man nur nach "S" suchen, ist die Eingabe nicht möglich. "S" <Enter> sucht nach "String", da "S" nach "String" vervollständigt wird.
  • Beispiel: Man Klickt auf ein Button, jedoch wenige ms zuvor überdeckt ein unmotiviert eingeblendetes Fenster den Button, nunmehr verarbeitet dieses neue Fenster den Click auf einen zufällig deckungsgleichen Button. Und das obwohl eine gewolltes Anklicken gar nicht möglich ist.
  • Beispiel: App "VR Networld Banking": Ist die App lange unbenutzt läuft die Session im Hintergrund ab, es ist keine Verbindung mehr vorhanden. Beendet man jetzt die App kommt die Frage "Abmelden"
  • Beispiel: App "VR Networld Banking": Besteht eine Session, diese hat aber keine Fokus, und es kommt eine Pushj nachricht wird man in einen neuen Anmeldeschirm geleitet obwohl eine gültige Session da ist. Es wird eine weitere Instanz der App gestartet anstelle den Eingabefokus auf die laufende aktuelle Session zu lenken
  • Beipsile: App "VR Networld Banking": geht der Anmeldevorgang sehr lange und das Handy schaltet das Display ab wird der anmeldevorgang nicht im Hintergrund zuende geführt, es gibt einen "technischen" Fehler. Ich muss immer aufs Display tippen um die App am Leben zu halten solange sie sich anmeldet.
  • Beispiel: App "VR Secure Go": Wird eine TAN erhalten verdeckt ein Fenster "aktualisiere Push Daten" diese TAN
  • Beispiel: Unwetterzentrale: man sieht eine karte, oben ist die Werbung am Laden, man klickt auf die Karte just in dem Moment rattert die Karten nach unten, man triff einen Bereich mit dem Klick, den man nicht wollte
  • Beispiel: Cookie-Warnungen: Wichtige Teile der Seite werden einfach überblendet, es ist keine echte Position für die Meldung vorgesehen
  • Beispiel: interne App-Makros: Apps werden intern teilweise durch Klicks gesteuert. Beispiel tunein Radio-App, mann wählt seinen Sender und sieht das "Play" Symbol. Eine Sekunde lang passiert nichts. Dann per Geisterhand dreht sich plötzlich das Rad. Der Playknopf wurde intern gedrückt, jetzt spielt das Radio los. Besser wäre es gewesen den Screen mit dem "Rad" zu beginnen, ev. mit dem Pause Symbol.

§1 Klickbarkeit

Ist ein Text oder ein Bild oder ein Icon anklickbar, so muss es in einer deutlich sichtbaren Weise grafisch anders ausgeprägt werden, dass dies deutlich wird. Bei einem MoveOver muss sich auch der Zeiger ändern. Ein Button muss von einem immer gleichen Rahmen umfasst sein, innerhalb des Textes muss "["Begriff"]" stehen oder #Begriff. Unterstreichen ist keine erlaubte Link-Symbolisierung. Einfärben (es wird gerne "Blau" genommen) ist keine erlaubte Link-Symbolisierung.

§2 Bewegungsmelder

Die beobachtete Fläche muss klar ausgewiesen werden. Bei MouseEntry / Leaf muss optisch die Fläche aufleuchten (ON/OFF). Bei ON darf die Fläche nicht verschoben werden, die GUI muss fixiert werden. Bei ON dürfen umliegende Bereiche verändert werden, bei OFF muss der "Originalzustand" wieder herstellt werden.

§3 Fokus

Der Eingabefokus darf niemals programmgesteuert dem aktuell sichbaren Eingabefeld entzogen werden, während die GUI Benutzereingaben erwartet. Das Einblenden eines Meldungsfensters während der Benutzer eine Eingabe tätigt ist ein solcher Fokusentzug. Ein Notifikationsbereich der sich verändert ist erlaubt.

§4 Eingabesicherheit

Direktes Abändern/Verfälschen der Eingabe, also automatisches Vervollständigen, automatisches Setzen eines Punktes usw. ist nicht erlaubt.

§5 Sichtbarkeit

Eingabebereiche dürfen nicht unmotviert überdeckt oder verschoben werden. Bei einer Grössenänderung muss das Zentrum (=Position des Eingabe-Cursors) beibehalten werden. Info Texte die den Sinn des aktuellen Eingabefeldes beschreiben müssen oberhalb des EIngabefeldes stehen, es muss damit gerechnet werden dass ein Touch Keyboard direkt unter dem Eingabefeld eingeblendet wird.

§6 Klicksichtbarkeit

Ein Klick auf Controls, die erst wenige ms sichtbar sind, darf nicht als Eingabe gewertet werden. Also wenn ein neu sichtbares Fenster eine alte GUI überdeckt und sich der Benutzer für einen Klick entschieden hat darf das neue Fenster diesen Klick-Event nicht verarbeiten.

§7 Reaktivität

Die GUI darf niemals auf Ergebnisse des Arbeitsprozesses warten, der Job wird an der Theke abgegeben, die GUI ist sofort wieder aktiv.

§8 Feedback

Ausgelöste Aktionen ("Tastendruck", "Klick", "Mausbewegung") muss ein Feedback auf der GUI erzeugen. Es darf nicht der Eindruck erweckt werden weitere, andere, derselbe Klick wäre nochmal möglich (zero Feedback). Optimalerweise sollte ein Button-Symbol eine "Action" symbolisieren (ausführen, stempeln, senden), nach dem Auslösen der Aktion sollte es zu einem Feedback-Symbol werden (Wartesymbol, grüner Haken) das NICHT Klickbar ist.

§9 Pausen

Jede Eingabe muss zurückgestellt werden können. Eingaben auf anderen Formularen müssen dann möglich sein. Verbot von "Topmost". Verbot von Modal.

§10 Variante

Jedes Formular muss dupliziert werden können. Es muss Testeingabe / Versuche verkraften ohne dass eine Aktion durchgeführt wird, erst anschließendes "Buchen" führt zur Aktion oder eben "Abbruch"

§11 Rückgängig

Jede lokale Eingabe die noch nicht "abgeschickt" ist, muss rückgängig gemacht werden können

§12 Barrierefreiheit

https://www.heise.de/newsticker/meldung/Firefox-mit-neuen-Tools-fuer-ein-barrierefreies-Web-4571249.html

Erreichte Meilensteine

  • HTTP/2 openSSL TLS 1.3 Connection
  • HTTP/2 Multiplexer
  • HTTP/2 erster statischer Content "/"

TO DO

  • HTTP/2 erste Login Seite
  • OLAP -> Migration auf Console
  • Auswertung -> Migration auf Console
  • Wegfall "AUSGANGSRECHNUNGEN"
  • OrgaMon Workflow Sheet?!
  • Idee zu "Rückgängig":
    • Pascal-Code erstellen der den Original-Zustand wieder herstellt.
    • Bei veränderten Dateien ein Snapshot-Unterverzeichnis generieren mit der "GEN-RUECKGAENGIG" als Name. Dies ist die Quelle für das Zurück-Kopieren der Original-Version. (ev. auch für FTP-Aktionen ermöglichen)
    • Integration Pascal-Skript mit "Rückgängig"

Client Konzepte

Datenhaltung

  • Tabellenwerte oder Eingabefelder sollen auf der Client Seite bereits mit dem HTML initial gehalten werden
    • Die JSON Daten sind Teil des HTML und wandern in die "Lokale Datenbank"
    • Dazu zusammen erhalten Sie einen ETAG, dieser kann einzeln abgefragt werden, das Resultat ist eine Info ob sich dieser ETAG geändert hat
    • Ev. auch ein COntext-ID mit einem ETAG, also wenn BEIDE gleich geblieben sind ist die Version in der Datenbank noch aktuell
    • Der Server soll bei Datenabfragen "ETAG" fähig sein, insbesondere für Daten-Requests, Also: Der Client frägt ein Dataset ab, ist es unverändert bekommt er nur das ETAG, das ist in der lokalen DB
  • Server liefert neue Daten nicht im HTML sondern in der Form, http://abral.altervista.org/apps/libri/elibri.json.php
  • Client benutzt eine Datenbank, die allen TABs zur verfügung stehen

sagen wir mal, wir haben: 

type
 DataModuleeCommerce = class(GhostAbleInterface)
 
 published
  TodaySettings : TStringList;
 end;

wir sagten ja ein lokaler OrgaMon kann auf TodayStrings zugreifen, als wäre das lokal

fetch()

https://fetch.spec.whatwg.org/

  • Alle Server Anforderungen gehen sofort zunächst in einen Sync-Buffer
  • Wenn mögich wird der Sync-Buffer Asynchron abgearbeitet
  • Mit dem Server wird per fetch() gesprochen
  • Ein Fetch kann misslingen
    • IP Change
    • Server Process Crash
    • Client Internet Connection Gab
    • Dies darf aber niemals zum Problem werden

Netzwerk

  • WAMP-formatted WebSocket messages (JSON, MsgPack and CBOR) are now nicely decoded for inspection in the Network panel.

Roadmap

im Einsatz

aktuell in Arbeit

  • HTTP/2 HPACK (Andreas)
  • erste Modelle des UI (Andre)
    • erster OrgaMon-Dialog ist "System"

kommende Aufgaben

  • "Eingabefeld",
  • "Tabelle"

Links

noch zu lesen

Abgerufen von „https://wiki.orgamon.org/index.php?title=OrgaMon-next&oldid=32032“