Polyzalos: Unterschied zwischen den Versionen

Aus OrgaMon Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:


* [[OrgaMon-next#FreePascal_Polyzalos]]
== 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 <code>writeln('-b-fett-/b-');</code> 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 ===
 
* der griechische Wagenlenker Polyzalos
* 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
* Polyzalos war der siegreiche Wagenlenker von Delphi
* http://www2.oberlin.edu/images/Art200-08/200-033.JPG
* https://www.john-uebersax.com/plato/plato3.htm
* https://commons.wikimedia.org/wiki/File:Charioteer_of_Delphi.jpg
* http://www.creaturearchives.com/animalia-chariot-allegory/
* http://3.bp.blogspot.com/-GwzDsFa2zIA/VCy-_jfVfcI/AAAAAAAAPtY/NtwPdmJIwiM/s1600/Dwie-Judha-Satria-chariot-allegory.jpg
* https://www.khanacademy.org/humanities/ancient-art-civilizations/greek-art/early-classical/v/charioteer-delphi
* https://www.insegnadelgiglio.it/prodotto/immagini-di-gela/
 
=== 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
 
* typischer Entwicklungszyklus
** Die Entwicklung soll also ausschliesslich mit der Lazarus-IDE stattfinden
** Coding von Funktionen, dabei erlaubter Mix von UI und Verarbeitungsaktionen
** 1. Compilierung zu einer Server.exe
** 2. Compilierung zu JavaScript und deploy auf Web-Bereich
** Der  Pascal-Quelltext soll "debug" infos mit ins JavaScript ausgeben können, so dass ...
** Start des Servers
** der Client-Browser bemerkt den erfolgreichen reconnect zum Server
** ... der native Lazarus-Debugger verwendet werden kann sobald generierter Code durchlaufen wird
** dabei wird Firefox das Debug-Protokoll an die Lazarus-IDE senden
*** https://docs.firefox-dev.tools/backend/protocol.html
*** https://searchfox.org/mozilla-central/source/devtools/docs/backend
*** https://searchfox.org/mozilla-central/source/devtools/docs/backend/client-api.md
*** Infos über den Internen Debugger: https://developer.mozilla.org/en-US/docs/Tools/Debugger/UI_Tour
** alternativ kann zum erzeugten JavaScript eine Sourcemap mitgegeben werden
*** https://developer.mozilla.org/de/docs/Tools/Debugger/How_to/Use_a_source_map
 
 
* 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 ====
 
* https://wiki.freepascal.org/pas2js_widgetsets
 
==== Hello World ====
 
program index;
uses
  p2020;
begin
  writeln('Hello World!');
end.
 
==== Slider ====
 
* https://www.youtube.com/watch?v=6P-nh3uNnsQ
 





Version vom 1. Dezember 2023, 19:25 Uhr

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