/*Antworten auf die Q&A zur Technology Stack Livestream*/

Zur portugiesischen Version wechseln     Zur englischen Version wechseln

Sprache und Framework

• Werden Alias-Tabellen weiterhin auf die gleiche Weise funktionieren?
  Das Konzept der Alias-Tabellen bleibt erhalten. Der aktuelle Weg funktioniert, indem man einfach eine weitere DataDictionary-Instanz derselben Entität mit einem anderen Objektnamen erzeugt.
   
• Wird das Konzept des „global file buffer“ und „local buffer“ mit Technology Stack Phase 2 der Vergangenheit angehören?
  Der globale Dateipuffer („global file buffer“) wird in den ersten Techstack-Releases verschwinden. Beim Konvertieren von Code, der auf den globalen Puffer angewiesen ist, kann eine globale Singleton-Instanz der DDO-Struktur als Ersatz verwendet werden, da die globalen Datenbank-APIs auf Data Dictionary-Instanzen umgeleitet werden.
   
• Wird es mit dem Redesign der Datentypen eine native Null-Unterstützung geben?
  Momentan laufen Experimente zur Null-Unterstützung bei Struct-Mitgliedern.
   
• Wie stark muss ich meinen bestehenden Code anpassen, damit er mit dem neuen Runtime funktioniert?
  Die Sprache ist weitgehend kompatibel, allerdings wurden einige sehr veraltete Techniken entfernt. Die Klassen haben jedoch Änderungen erfahren, z. B. eine neue cHttpClient-Klasse anstelle der cHttpTransfer-Klassen. Das Windows UI Framework wird vorerst nicht enthalten sein, da der Fokus zunächst auf Web und Flextron liegt. Der gesamte Web UI Object Code sollte jedoch sehr kompatibel bleiben, da das gleiche Web App Framework verwendet wird, das Sie gewohnt sind.
   
• Kann man weiterhin den tabellenname.spaltenname-Symbol verwenden, wenn man im Quellcode auf eine Tabellenspalte zugreift?
  Ja, alle globalen Datenbank-APIs wurden auf die DataDictionaries umgeleitet. Solange Sie also den Tabellennamen durch ein DD-Objekt ersetzen, sollte alles funktionieren. Für Abwärtskompatibilität ist es vermutlich ausreichend, ein Objekt mit dem gleichen Namen wie Ihre Tabelle zu erstellen.
   
• Was wird der Ersatz für die Eigenschaften data_file und data_field sein?
  Alles, was Hinweise darauf gibt, wie unser Code beim Zugriff auf Datenbanken aussehen wird, ist interessant. Sie behalten ihre Funktion, da data_file nun durch einen Handle auf das DataDictionary-Objekt ersetzt wird. Bestehender Code, der diese verwendet, sollte weiterhin funktionieren.
   
• Es gibt keine Dateiliste mehr – wie werden Änderungen daran gehandhabt?
  Das Studio wird den Tabellen-Editor und andere bekannte Werkzeuge enthalten. Neu ist, dass Änderungen nun auch im Code möglich sein werden.
   
• Erlaubt das Client Runtime die Nutzung von Funktionstasten wieder?
  Das Client Web Application Framework unterstützt bereits Funktionstasten über Key Handlers. Diese Funktionalität bleibt erhalten.
   
• Um das Thema Funktionstasten zu klären: Reagiert ein Webapp-Client z. B. auf F2 = Speichern?
  WebApps reagieren bereits auf Funktionstasten, einschließlich F2. Wenn der Fokus jedoch nicht auf einem Web Control liegt, kann der Browser seine Standardfunktion ausführen.
   
• Wenn ein Browser z. B. fn+Page Down benutzt, um auf einer Webseite zu scrollen, kann das nicht als nächster Datensatz fungieren?
  Das Standardverhalten von Browser-Funktionstasten lässt sich in den meisten modernen Browsern überschreiben.
   
• Es wird doch sicher Assistenten geben, z. B. „Struct/Entity aus DB-Tabelle erstellen“, oder?
  Intern gibt es bereits Werkzeuge, um DataFlex-Tabellendefinitionen über das Studio in Entity-Definitionsdateien umzuwandeln. Assistenten wären ein nächster Schritt.
   
• Kann man beim Definieren von Tabellen als Structs auch Indizes angeben?
  In der aktuellen internen Version geben Sie Spalten, Attribute, Indizes und Beziehungen zwischen Entitäten an.
   
• Wie könnte die Syntax innerhalb von Prozeduren wie Creating oder Update in einer DD-Klassendefinition aussehen? Man möchte vielleicht eine übergeordnete Tabelle aktualisieren, kennt aber nicht den DD-Objektnamen.
  Diese Aufgaben können bereits über Methoden erledigt werden, um die zuständige Tabelle zu finden. Die Dokumentation zum aktuellen Stack beschreibt dies. Je nach Anwendungsfall müssen noch Details geklärt werden. Langfristig hoffen wir, dass die Vorgehensweise geschätzt wird, auch wenn sie nicht komplett kompatibel ist.
   
• Werden die Methoden und Eigenschaften der neuen HTTP Transfer Klasse (cHTTPClient?) ähnlich bleiben oder muss ich größere Änderungen vornehmen?
  Es gibt einige Änderungen, aber die API bleibt vertraut und ist für die nächsten 20+ Jahre ausgelegt. Außerdem kann diese API jetzt auf allen Plattformen verwendet werden (WebAssembly, Windows, etc.).

Studio

• Wie sieht es mit dem Studio aus – wird es webbasiert oder nur für Windows sein?
  TechStack wird das bestehende Studio verwenden, das auch in absehbarer Zeit eine Windows-Anwendung bleibt. Die langfristige Vision ist jedoch, ein Studio auf Web-Technologie-Basis zu entwickeln.
   
• Wird das Studio zukünftig auf Linux und macOS laufen?
  Das ist das langfristige Ziel. Anwendungen werden zunächst über WebAssembly laufen und später auch nativ auf Linux und macOS. Für das Studio selbst bewegen wir uns schrittweise in Richtung Web-basiert. Das würde bedeuten, dass es als FlexTron-Anwendung auf Windows, macOS oder Linux oder sogar in der Cloud laufen könnte. Einen festen Zeitplan gibt es noch nicht, aber alle heutigen Entscheidungen sind mit diesem Ziel verbunden. Vorerst wird der Technology Stack weiterhin das aktuelle Studio nutzen.
   
• Wird DataFlex andere Editoren wie Visual Studio Code unterstützen?
  Das wird aktiv untersucht. Wir planen nicht, das aktuelle Studio zu ersetzen, wollen aber offener für externe Tools werden. Zum Beispiel arbeitet derzeit ein Praktikant an einem Language Server (LSP) für DataFlex. LSPs ermöglichen Features wie IntelliSense in Editoren wie VS Code. Das würde anderen Tools und Editoren eine bessere Unterstützung von DataFlex ermöglichen. Langfristig öffnet das auch die Tür, den Editor im Studio durch etwas Moderneres wie Monaco (den Editor von VS Code) zu ersetzen.

Daten

• Was passiert, wenn man das Datenbankmodell in die Anwendung kompiliert und diese dann bei verschiedenen Firmen mit unterschiedlichen Feldgrößen läuft?
  Das System wird auf jeden Fall flexibel genug sein, um solche Fälle zu handhaben.
   
• Wird DataFlex mit einem Standard-Datenbank-Backend oder einer kostenlosen empfohlenen Datenbank kommen, um die aktuelle eingebettete Datenbank für neue Programmierer zu ersetzen?
  Derzeit planen wir, SQLite zu ersetzen, um sowohl die Einfachheit einer Einzeldatenbank-Datei als auch die Leistung von SQL zu bieten.
   
• Wie stellen Sie sich die Datenverbindung zwischen Client und Server vor?
  Diese Verbindung ist natürlich komplett optional, inklusive Offline-Unterstützung. Man kann sich manuell mit dem cHttpClient verbinden oder die HttpDatabaseDriver verwenden, die wir bereitstellen werden, um mit Data Binding und Data Dictionaries zu arbeiten.
   
• Tipps, wie man neue Updates (und Datenbankänderungen) nahtlos an OnPremise-Kunden schnell ausrollen kann?
  Die Restrukturierung der Datenbanktabellen ist noch nicht komplett entworfen, aber wir werden das bei der Entwicklung berücksichtigen.
   
• Die Data Dictionary API ist sehr ausführlich, wie funktioniert das?
  Data Dictionaries sind komplett in DataFlex-Code neu geschrieben, sodass man sie besser debuggen und nachvollziehen kann, was passiert. Wir werden sie auch refaktorieren und zusätzliche Abwärtskompatibilitätsschichten für diejenigen bereitstellen, die diese benötigen.

FlexTron und Windows

• Wie wird das Modell für eine FlexTron-Anwendung aussehen?
  Vermutlich wird weiterhin der DataFlex-Client benötigt, um die .exe auszuführen, aber die neuere Runtime wird innerhalb der lokalen Control Hosts laufen. Obwohl es möglich wäre, würde dies nur zusätzliche Overhead-Kosten verursachen. Daher wird die neue Runtime nativ unter Windows laufen, so wie es jetzt der Fall ist, und das aktuelle FlexTron-Paradigma mit einem reinen JS Web App Framework verwenden.
   
• Wie lange werden native Windows-Desktop-Anwendungen unterstützt?
  Der Technology Stack Runtime wird native Windows-Desktop-Anwendungen in den ersten Versionen nicht unterstützen. Und selbst wenn dies der Fall ist, wird die Umstellung großer bestehender Anwendungen auf den neuen Stack eine Investition sein, die nicht jeder Kunde tätigen kann. Deshalb beabsichtigen wir, die klassische Runtime noch lange zu unterstützen. Das bedeutet, dass wir weiterhin Updates bereitstellen werden, um Fehler zu beheben und Funktionen hinzuzufügen – zumindest für absehbare Zeit.

Zeitplan

• Wann ist mit der Technology Stack zu rechnen?
  Wir hoffen, so schnell wie möglich auf eine Technical Preview hinzuarbeiten. Diese wird den Entwicklungszyklen ähneln, die wir während der Entwicklung von DataFlex 20.0 erlebt haben.
   
• Wann können wir mit den ersten Versionen eines Docker-Images rechnen?
  Dies wird voraussichtlich in Phase 2 erfolgen, wenn wir einen neuen Web App Server entwickeln, der nicht mehr vom Internet Information Server abhängt und auf anderen Plattformen als Windows laufen wird. Dann sollte man in der Lage sein, ein veröffentlichtes WebAppServer-Image herunterzuladen.

Sonstiges

• Arbeitet DataFlex mit KI?
  Ja, wir experimentieren mit KI für Funktionen wie Codevervollständigung. Man kann es sich vorstellen wie einen praktischen Co-Piloten für Entwickler. Es steckt noch in den Anfängen, aber wir erforschen, wie KI die Entwicklungserfahrung unterstützen und verbessern kann.
   
• Warum haben wir einen numerischen Primärschlüssel, warum nicht direkt UUID verwenden?
  Die meisten Datenbanksysteme bieten automatische Nummerierung an, und wir beabsichtigen, die automatische Nummerierung des Backends zu nutzen, wo möglich. Wenn ein Backend UUID unterstützt, wollen wir das ebenfalls unterstützen. UUID vs. numerische Schlüssel ist auch eine Frage der Präferenz.
   
• Wie wird die Sicherheit gewährleistet? Wie weiß der Server, dass es sich tatsächlich um die DataFlex-Anwendung handelt?
  Die Sicherheit bleibt wie bei der normalen Webentwicklung in jeder Sprache bestehen: Man muss weiterhin Authentifizierungsmechanismen und Session-Token-Prüfungen implementieren.
   
• Wird DataFlex jemals Windows-Authentifizierung in WebApp erlauben, sodass Nutzer ihre Windows-Anmeldedaten verwenden können?
  Das ist bereits auf verschiedene Weisen möglich. Eine Methode läuft auf IIS-Ebene, wo die Authentifizierung erfolgt und in DataFlex können dann HTTP-Header im Session Manager geprüft werden, um den angemeldeten Nutzer zu ermitteln. Außerdem arbeiten wir an einer Single-Sign-On-Bibliothek mit IntraID-Unterstützung für Azure Cloud.
   
• Wie wird die Lizenzpolitik für das neue Runtime (z. B. Docker-Images, WebAssembly) aussehen?
  Dazu haben wir aktuell noch keine Antwort. Es ist jedoch zu erwarten, dass für WebApp Server Deployments eine ähnliche Lizenzierung gilt wie derzeit.
   
• Sie sagten, User Counting ist in JavaScript nicht möglich. Wird es in WebAssembly möglich sein?
  Nein, da beide auf dem Client laufen. Wie in der Webentwicklung kann einem Client nie vertraut werden, dass er sicher und manipulationsfrei ist.
   
• Es gibt keine Workspace-Datei, warum?
  Im WebAssembly-Umfeld wollen wir nicht von vielen externen Dateien zur Laufzeit abhängig sein. Daher wird es im WebAssembly-Umfeld keine Workspace-Datei geben. Auf anderen (nativ) Plattformen könnte die Workspace-Datei zurückkehren, wenn wir den Bedarf sehen.
   
• Ist der Umzug von den USA nach Europa der Grund für diese Veränderung?
  Nicht direkt. Das hätte auch in den USA passieren können. Unser europäisches R&D-Team war bereits an der Entwicklung von DataFlex beteiligt und konnte neue Talente gewinnen, was uns ermöglicht hat, Projekte wie dieses anzugehen.
   
• Sind Unit Tests Teil des zukünftigen DataFlex-Pakets oder eine Zusatzbibliothek?
  Derzeit sind sie eine Zusatzbibliothek, die Sie hier finden können.
   
• Wie sieht es mit GitHub- und Git-Integration aus?
  Git-Integration im Studio ist ein beliebter Wunsch: Arbeiten mit Repositories, Änderungen sehen und direkt commiten. Das steht definitiv auf unserer Wunschliste, wird aber aktuell nicht aktiv entwickelt. Was wir aktiv vorantreiben, ist eine bessere Integration von DataFlex mit GitHub, sodass DataFlex als Sprache erkannt wird, mit Syntax-Highlighting und verbessertem Suchsupport. Außerdem veröffentlichen wir mehr Open-Source-Code auf GitHub, um die Community zu unterstützen und transparenter zu sein.