Polyzalos

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen

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 der Server-Datenbank mit einer lokalen sqlite3-Datenbank (als .wasm)
    • 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


Links

Abgerufen von „https://wiki.orgamon.org/index.php?title=Polyzalos&oldid=32468“