Polyzalos

OrgaMon Polyzalos

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

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

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

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

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
Konsolenanwendungen oder Textmode- Anwendungen sind der Standard
Grafik wird völlig selbst berechnet und ausgegeben

Anwendungen sind Konsolenanwendungen oder grafische Anwendungen (Windows)
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)

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 der Server-Datenbank mit einer lokalen sqlite3-Datenbank (als .wasm)
- Teil des Frameworks https://docs.emmet.io/cheat-sheet/ zur Hilfe bei html Erstellung

program index;

uses
 p2020;

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