Polyzalos

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Light bulb  Hinweis:  Polyzalos befindet sich noch in Entwicklung, eine erste Demo erschien 2023, mit einer ersten Anwendung wird in 2024 gerechnet

Polyzalos ist ein neuer Ansatz Mehrplatz- Anwendungen mit Freepascal und Lazarus zu entwickeln.
OrgaMon kann sich damit von der Win32- Plattform lösen, auch wird nicht mehr Delphi als Compiler eingesetzt.
Zu einer Polyzalos-Anwendung gehören immer 2 Targets, für die Code erstellt werden muss.
Für den Programmierer und den Anwender entsteht aber der Eindruck einer direkt bedienbaren App. In Wirklichkeit ist ein Webanteil für das GUI und ein Serveranteil für die Programmlogik entstanden

  • Im Zentrum steht der FreePascal-Compiler der pro Projekt-Compilierung 2x den Code compilieren muss.
    • Erster Compiler-Lauf: Compilierung für die Serverplattform, ein Compilat cOrgaMon.exe (z.B. Target Win64), also die inkludiert ein HTTP2-Server (Kern) mit Verarbeitungs-Code (Logik).
    • Zweiter Compiler-Lauf: Compilierung nach JavaScript und Auslieferung der veränderten Code-Anteile in ein Webserver-Verzeichnis
    • Start der Anwendung: Ein Browser wird gestartet mit der Adresse des eben erzeugten Web-Anteiles, der Server dieser Website ist cOrgaMon.exe
  • Der Programmierer vermischt weiterhin UI-Code mit Anwendungs-Code, in Wirklichkeit
    • verteilt der Compiler den Code auf den Server (NON-UI-Anteile) und außerdem 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
    • sind Methoden auf dem Client nicht ausführbar (sie erfordern Server-Resourcen wie Dateisystem, Datenbank, oder complexe Bibliotheken) und erfordern somit Aktionen auf dem Server, dies erfolgt grundsätzlich "nonblocking", also der Client wartet nie, sondern setzt nur Requests ab
    • sind aber Logik-Anteile des Programmes so trivial oder deren Ergebnise einfach nicht persistent, wird der Code direkt in der GUI ausgeführt ohne Beteiligung des Servers

Download

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 auf der Web-Seite eine API zu einer statischen css+html+JavaScript Monolith Web-Visual-Component-Library-Operating-System (WVCL-OS)
    • UI-OS ist ein Unterprojekt von Polyzalos und soll langfristig auch die komplette 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

App

  • die App.js ist das 2. Compilat das von cOrgaMon ausgeliefert wird
  • Darin sind lokale "onButtonpressed" Events implementiert, remote Aktionen gehen an den Service-Worker (PostMessage)

ServiceWorker

SQLite3.wasm

  • Only the ServiceWorker see a SQLite3 Database with forms and propertys (edit.text, grids.data)
  • every Request to a "Form" is generated by the ServiceWorker with persistent Data from the DB
  • The DB is synced with cOrgaMon and App.js storage Format is JSONB

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
  • (unsicher) Ein grober Funktionstest kann so immer in der IDE 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
    • die lfm werden zum Client übertragen der sie in einer Offline-Datenhaltung speichert (Versioning der lfm-Files!)
  • die lfm werden mit ihren Propertys als JSON, dann JSONB in der SQLite3 DB des ServiceWorkers gespeichert
  • der Worker erzeugt auf "fetch" der app.js das Formular als html5
    • Im Endausbau soll Lazarus nativ in ein Chromefenster laufen, ev. gibt es auch mal einen lfm Designer fürs Web
    • die compilat erstellung soll aber immer auf einer nativen Plattform ausgeführt werden
  • der Worker 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 Worker implementiert eine WCL welcher TButton, TListbox, TLabel kennt, und das zugehörige html5+js ausliefert

aktuelle Probleme

  • Im ServiceWorker kann das OPFS wegen nicht vollständiger API nicht genutzt werden
    • Lösung: Auf das AsyncKKKK verzichten
    • ganze klar Dokumentieren, wie persistenz im ServiceWorker erreicht werden kann

Meilensteine

08.12.2023 ServiceWorker und sqlite3 laufen, persistenz ist kvv

TO DO

  • "SQLite3 Worker" innerhalb des ServiceWorkers erstellen, in der Hoffnung dass hier OPFS geht!
    • 08.12.2023: gebe die OPFS Forderung auf akzeptiere dass die Persistenz halt woanders liegt

Namensherkunft

  • Sein Gewinn eines Wagenrennens wurde einst in einem Büstenmonument verewigt
  • das Monument wurde ausgegraben es ist aber nicht mehr vollständig erhalten
    • So stellt sich die Wissenschaft das komplette Monument vor: http://www2.oberlin.edu/images/Art200-08/200-033.JPG
    • In der Skizze steht der Siegreiche auf dem Wagen als Lenker, ich denke das ist die akzeptierte wissenschaftliche Stand (Meine persönliche Meinung ist aber dass er als "Sponsor" vor den Pferden stand, die Wagenlenker sind in der Regel nackt dargestellt, der Künstler hat viel Arbeit in die Darstellung der Füße gelegt, diese wären auf dem Wagen gar nicht sichtbar)
    • https://www.john-uebersax.com/plato/plato3.htm
    • Der Sponsor oder siegreiche konnte (auch) den Gewinnerkranz für sich beanspruchen, war aber bekleidet
  • 2 Pferde, Kelpies Falkirk Scotland
  • Er führt ruhig einen Streitwagen mit 2 sehr unterschiedlichen Pferden (Server/Pascal, Browser/JS)
    • ev. auch auseinanderstrebenden Pferden
    • ein Pferd symbolisiert die JavaScript Seite des Browsers
    • das andere Pferd symbolisiert die Pascal Seite des Servers

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

Delphi

  • 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)

FreePascal Target 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

Hello World

program index;

uses
 p2020;

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

Slider

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