KI-Integration
ZENTRALISIEREN SIE KI-ANBIETER UND -MODELLE MIT WIEDERVERWENDBAREN ALIASEN
KI-Anbieter und -Modelle werden nun in einem eigenen KI-Reiter in den Einstellungen definiert und anwendungsweit wiederverwendet.
Jeder Anbieter speichert seine Basis-URL, seinen API-Schlüssel und optionale Identifikatoren. Verbindungen können direkt getestet werden, sodass der Zugriff vor jedem Aufruf überprüft wird. Nach der Konfiguration werden die Anbieter Teil der Projekteinstellungen und folgen derselben Bereitstellungslogik über Struktur-, Benutzer- oder Datenebene-Konfigurationen hinweg.
Die Modellnutzung wird durch zwei Ansätze vereinfacht. Sie können Modelle über ein anbieterbasiertes Format wie ProviderName:ModelName referenzieren oder Modell-Aliase definieren, die einen benutzerdefinierten Namen einem Anbieter und einer Modell-ID zuordnen. Wenn das Attribut model mit einem Alias übereinstimmt, ermittelt 4D automatisch die zugehörige Anbieter- und Modellkonfiguration.
Dadurch entfällt die Notwendigkeit, Anbieterdetails oder Modellkennungen im gesamten Code zu wiederholen. Das Wechseln von Anbietern, das Aktualisieren von Anmeldedaten oder das Ersetzen von Modellen erfordert keine Änderungen in mehreren Methoden.
Anbieter- und Modellkonfigurationen bleiben zur Laufzeit über die Klasse OpenAIProviders zugänglich. Sie können verfügbare Anbieter überprüfen, Modellaliase abrufen oder das Verhalten bei Bedarf dynamisch anpassen.
Die Verwaltung der KI-Integration wird mit zunehmender Skalierung einfacher. Die Konfiguration bleibt zentralisiert, die Modellnutzung bleibt konsistent und Ihr Code konzentriert sich weiterhin auf die Anwendungslogik statt auf externe Einstellungen.
Benutzeroberfläche
LIQUID GLASS-LOOK FÜR 4D-FORMULARE AUF macOS
In 4D 21 R3 übernehmen Formulare unter macOS automatisch den Liquid-Glass-Systemstil.
Standardobjekte wie Schaltflächen, Listen und Menüs folgen den von macOS definierten aktualisierten Abständen, Transparenzwerten und visuellen Rückmeldungen. Die Darstellung ändert sich optisch, während die Formularlogik und die Ereignisbehandlung unverändert bleiben.
Da der Stil Transparenz und abgerundete Formen einführt, erfordern Layouts mit engen Abständen oder überlagerten Elementen möglicherweise geringfügige Anpassungen.
Anwendungen passen sich den aktuellen macOS-Konventionen an, ohne dass sich die Art und Weise ändert, wie Formulare erstellt werden.
MODERNE BENUTZEROBERFLÄCHEN MIT FLUENT UI UND LIQUID GLASS ERSTELLEN
In 4D 21 R3 unterstützt die Objektbibliothek Fluent UI unter Windows und Liquid Glass unter macOS.
Bestehende Komponenten werden unter Verwendung des ausgewählten Designsystems gerendert, ohne dass ihre Definition geändert wird. Dieselben Formulare passen sich plattformübergreifend an und sorgen so für eine konsistente und moderne Benutzeroberfläche ohne Neugestaltung.
Aktualisierte Komponenten folgen aktuellen Entwicklungspraktiken und verfügen über übersichtlichere Objektmethoden, wenn sie hinzugefügt oder neu generiert werden.
Die Benutzeroberfläche entwickelt sich plattformübergreifend weiter, während Struktur und Logik unverändert bleiben.
MODERNE FORMULARE MIT PAPIEROPTIMIERTER DARSTELLUNG DRUCKEN
In 4D 21 R3 werden Formulare mit modernen UI-Stilen automatisch für den Druck angepasst.
Widgets werden in flache, monochrome Darstellungen umgewandelt, und visuelle Effekte wie Transparenz und Schatten werden entfernt. Layout, Ausrichtung und Abmessungen bleiben erhalten, und die gedruckten Werte entsprechen dem aktuellen Zustand, einschließlich nicht gespeicherter Daten.
Die Umwandlung erfolgt automatisch und liefert konsistente Ergebnisse unter macOS und Windows, ohne dass Änderungen an der Drucklogik erforderlich sind.
NETZWERK
LEGACY-NETZWERK ENTFERNT
In 4D 21 R3 wurde die Legacy-Netzwerkschicht entfernt.
Neue Projekte verwenden standardmäßig QUIC, während Binärdatenbanken ServerNet nutzen. Die Netzwerkschicht wird bei der Erstellung basierend auf dem Anwendungstyp festgelegt.
Bestehende Anwendungen, die noch auf Legacy verweisen, bleiben kompatibel. Zur Laufzeit verwendet 4D ServerNet, sodass Anwendungen weiterhin auf einer unterstützten Schicht laufen, ohne dass sofortige Änderungen erforderlich sind.
Unterstützte Protokolle werden zur Basis, während Legacy nicht mehr Teil der Konfiguration ist.
EMAIL-EREIGNISSE IN ECHTZEIT MIT IMAP IDLE EMPFANGEN
In 4D 21 R3 unterstützt IMAPTransporter das IDLE-Protokoll, sodass Anwendungen auf Änderungen im Postfach reagieren können, sobald diese eintreten.
Der Befehl „IMAP New Transporter“ akzeptiert nun ein Listener-Objekt, in dem Callback-Funktionen für Ereignisse wie onMailCreated, onMailDeleted und onFlagsModified definiert werden können. Jeder Callback erhält den Transporter und ein Ereignisobjekt mit Details wie Nachrichtenanzahl, Sequenznummer oder Aktualisierungsflags.
Benachrichtigungen werden über die Eigenschaft „notifier“ gesteuert. Der Aufruf von notifier.start() abonniert Serverereignisse, während notifier.stop() diese pausiert. Wenn aktiv, hält der Transporter eine Live-Verbindung aufrecht und liefert Ereignisse, anstatt sich auf periodisches Abfragen zu verlassen.
Dadurch wird die E-Mail-Verarbeitung von geplanten Überprüfungen auf einen ereignisgesteuerten Ablauf umgestellt. Anwendungen bleiben mit dem Status des Postfachs synchronisiert, reduzieren unnötige Anfragen und können die Benutzeroberfläche aktualisieren oder Logik auslösen, sobald Änderungen auftreten.
4D Write Pro
DOKUMENTE MIT HIERARCHISCHEN NUMMERIERTEN LISTEN STRUKTURIEREN
In 4D 21 R3 entwickeln sich nummerierte Listen in 4D Write Pro von einer einfachen Formatierung zu einer strukturierten Dokumentorganisation. Sie können nun eine hierarchische Nummerierung über mehrere Ebenen hinweg definieren, wodurch Abschnitte, Unterabschnitte und verschachtelte Inhalte automatisch konsistent bleiben.
Die Nummerierung wird über verknüpfte Absatzformate definiert, wobei jede Ebene einer strukturierten Hierarchie folgt. Formate wie 1, 1.1 und 1.1.1 werden automatisch generiert.
Wenn Inhalte hinzugefügt, entfernt oder neu angeordnet werden, aktualisiert sich die Nummerierung auf allen Ebenen ohne manuelle Anpassung.
Dieser Ansatz macht es überflüssig, die Nummerierung neu zu starten oder per Code zu pflegen. Stattdessen folgt die Nummerierung der von Ihnen definierten Struktur und gewährleistet so Konsistenz in langen oder komplexen Dokumenten.
4D-Sprache
Direkter Zugriff auf Benutzersitzungen über den 4D CLIENT
In 4D 21 R3 wurde der Befehl Session auf den 4D-Client erweitert und gibt nun das Remote-Sitzungsobjekt anstelle von Null zurück.
Auf Sitzungsdaten wie die Sitzungs-ID, den Benutzernamen und den Kontext kann direkt vom 4D-Client aus zugegriffen werden. Funktionen wie createOTP(), getPrivileges(), hasPrivilege() und isGuest() können lokal aufgerufen werden, während sie weiterhin die Serversitzung widerspiegeln.
Dadurch entfällt die Notwendigkeit, Code nur für den Zugriff auf Sitzungsinformationen umzustrukturieren. Die Logik kann dort verbleiben, wo sie verwendet wird, was die Abläufe übersichtlicher macht und die Anzahl der in Client-Server-Anwendungen erforderlichen Zwischenmethoden reduziert.
Hybride Szenarien werden zudem direkter. Ein Client kann ein OTP generieren und eine Qodly-Seite innerhalb desselben authentifizierten Kontexts ohne zusätzliche Koordination öffnen.
Serverseitige Einschränkungen bleiben unverändert. Funktionen zur Änderung von Berechtigungen werden weiterhin nur auf dem Server ausgeführt, und der Client-Speicher bleibt getrennt.
Die Sitzungsverwaltung lässt sich leichter in bestehenden Code integrieren, ohne diesen hinsichtlich des Ausführungskontexts umstrukturieren zu müssen.
AUSFÜHRUNG VON SHARED- UND SESSION-SINGLETON-FUNKTIONEN AUF DEM SERVER
In 4D 21 R3 unterstützen Funktionen von Shared- und Session-Singletons das Schlüsselwort server, wodurch sie auf dem Server ausgeführt werden können, selbst wenn sie von einem 4D-Client aufgerufen werden.
Die Funktion wird auf der serverseitigen Instanz des Singletons ausgeführt. Wenn keine Instanz vorhanden ist, wird sie automatisch erstellt, was bedeutet, dass ein Singleton sowohl auf dem Client als auch auf dem Server mit unterschiedlichen Eigenschaftswerten existieren kann.
Dies gilt für Shared- und Session-Singleton-Klassen. Das Schlüsselwort local kann zur Verdeutlichung weiterhin verwendet werden, während ORDA-Datenmodellfunktionen zur Eindeutigkeit auch server akzeptieren.
Parameter und Rückgabewerte müssen streambar sein und demselben Ausführungsmodell wie serverseitige ORDA-Funktionen folgen.
Sitzungsbezogene Logik, Shared-Memory-Operationen und serverabhängige Verarbeitung können nun innerhalb des Singletons verbleiben, das sie definiert, ohne in Projektmethoden oder ORDA-Funktionen verschoben zu werden, um den Ausführungsort zu steuern.
Dynamischen Text in echte ausführbare Methoden umwandeln
In 4D 21 R3 ermöglicht die neue Klasse 4D.Method, dass als Text gespeicherter Code als native Methode ausgeführt wird.
Eine Methode wird mit 4D.Method.new() erstellt und verhält sich wie eine native Methode. Sie kann ausgeführt, in Objekten gespeichert oder mit call() und apply() aufgerufen werden. Parameter werden strukturiert übergeben, und This gibt während der Ausführung das hostende Objekt zurück.
Vor der Ausführung validiert checkSyntax() den Quellcode und gibt detaillierte Informationen zu Fehlern und Warnungen zurück, einschließlich Zeilennummern.
Dadurch lässt sich dynamische Logik einführen, ohne die Kontrolle zu beeinträchtigen. In Datenbanken oder externen Quellen gespeicherter Code kann mit demselben Sprachmodell validiert und ausgeführt werden, was die Anpassung zur Laufzeit zuverlässiger und wartungsfreundlicher macht.
Die Ausführung bleibt über alle Umgebungen hinweg konsistent, da Methoden selbst in kompilierten Anwendungen im interpretierten Modus ausgeführt werden.
Dynamisches Verhalten wird in die Anwendung integriert, anstatt ein isolierter Mechanismus zu bleiben.
JSON MIT MODERNEN SCHEMA-STANDARDS VALIDIEREN
In 4D 21 R3 unterstützt der Befehl JSON Validate nun den neuesten JSON-Schema-Standard (Entwurf 2020-12).
Schemas können nun bedingte Logik, erweiterte Einschränkungen und erweiterte Formatvalidierung enthalten. Dadurch können mehr Validierungsregeln direkt im Schema ausgedrückt werden, anstatt sie im Code zu implementieren.
Dadurch kann Validierungslogik systemübergreifend genutzt werden, ohne dass Duplikate entstehen. Backend-, Frontend- und externe Dienste können auf dasselbe Schema zurückgreifen, wodurch das Verhalten beim Datenfluss zwischen ihnen einheitlich bleibt.
Die Fehlermeldung ist präziser, wodurch Validierungsprobleme leichter identifiziert und behoben werden können. Bestehende Draft-04-Schemas werden weiterhin unterstützt, und die Validierungs-Engine wird automatisch basierend auf dem Attribut $schema ausgewählt.
KONSISTENTE VALIDIERUNG VON DATEN IN JSON-SCHEMAS
In 4D 21 R3 behandelt JSON Validate Datumsangaben einheitlich, unabhängig davon, ob sie als Zeichenfolgen oder als native 4D-Datumswerte gespeichert sind.
Die Validierung folgt der Schemadefinition, unabhängig davon, wie das Datum intern dargestellt wird. Dies beseitigt Inkonsistenzen beim Datenaustausch zwischen JSON, APIs und der internen Verarbeitung.
Schemas bleiben die Referenz für Validierungsregeln, ohne dass vor der Validierung zusätzliche Konvertierungslogik erforderlich ist.
FEHLER BEI BEFEHLSPARAMETERN FRÜHER IM EDITOR ERKENNEN
In 4D 21 R3 wurde die Syntaxprüfung erweitert, um Befehlsparameter direkt im Editor anhand der in der Dokumentation definierten Typen und Syntaxmuster zu validieren.
Wenn ein Befehl einen bestimmten Typ wie Text, Integer, Object, Pointer oder eine zuweisbare Variable erwartet, werden ungültige Argumente nun bereits beim Schreiben des Codes erkannt, anstatt erst später zur Laufzeit oder bei der Syntaxprüfung aufzutauchen. Dies gilt auch für dokumentierte Parameter mit mehreren Typen, variadische Parameter und variadische Parametergruppen.
Die Prüfungen sind nun präziser für häufige Fälle wie falsche Argumenttypen, die Übergabe nicht zuweisbarer Werte an Stellen, an denen eine Variable erforderlich ist, oder Befehlssignaturen, die von einer bestimmten dokumentierten Syntax abhängen. Die bestehende Befehlssyntaxprüfung wird hier nicht ersetzt. Sie wird erweitert, um sowohl im 4D-Code-Editor als auch in VS Code einen umfassenderen und genaueren Satz von Parameterregeln abzudecken.
Dadurch entspricht die Befehlsverwendung stärker den tatsächlichen Definitionen in der Dokumentation, sodass ungültige Aufrufe früher erkannt und korrigiert werden, bevor sie sich weiter im Entwicklungszyklus ausbreiten.
4D-Komponente
VERWALTEN SIE GITLAB-KOMPONENTENABHÄNGIGKEITEN ÜBER DIE PROJEKTSCHNITTSTELLE
In 4D 21 R3 unterstützt die Schnittstelle „Projektabhängigkeiten“ nun GitLab-Repositorys und erweitert damit das bestehende Abhängigkeitsmanagement über GitHub hinaus.
Komponenten können direkt aus einem GitLab-Repository hinzugefügt werden, entweder über eine vollständige URL oder einen Repository-Pfad. Private Repositorys werden über persönliche Zugriffstoken unterstützt, die pro Server definiert und über verschiedene Abhängigkeiten hinweg wiederverwendet werden können.
Die Versionsauswahl folgt derselben Logik wie bei anderen Komponenten. Abhängigkeiten können auf die höchste verfügbare Version, ein bestimmtes Tag oder eine semantische Version abzielen, was eine präzise Kontrolle darüber ermöglicht, was in das Projekt integriert wird.
Nach dem Hinzufügen verhalten sich GitLab-Komponenten wie jede andere Abhängigkeit. Sie werden in der Oberfläche „Projektabhängigkeiten“ aufgelistet, beim Neustart des Projekts installiert und können aktualisiert, überprüft oder entfernt werden, ohne die Umgebung zu verlassen.
Die Abhängigkeitsverwaltung wird über alle Repository-Quellen hinweg konsistent, sodass auf GitLab gehostete Komponenten denselben Lebenszyklus und dieselben Versionierungsregeln befolgen wie der Rest des Projekts.
Visual Studio Code-Erweiterung
ROLLEN, BEFUGNISSE UND HTTP-HANDLER VISUELL IN VS CODE BEARBEITEN
Strukturierte Projektdateien können nun über spezielle UI-Editoren direkt in VS Code bearbeitet werden.
Rollen und Berechtigungen sowie HTTP-Handler werden in einer visuellen Oberfläche statt als rohes JSON geöffnet. Felder sind übersichtlich angeordnet, Optionen sind eindeutig und Konfigurationen können aktualisiert werden, ohne durch verschachtelte Strukturen navigieren oder die Syntax manuell verwalten zu müssen.
Die Validierung ist integriert. Ungültige Konfigurationen lassen sich schwerer einfügen, und häufige Fehler aufgrund von Formatierung oder Struktur werden vermieden, bevor sie die Laufzeit erreichen.
Die gleichen Dateien bleiben jederzeit als Text zugänglich. Je nach Aufgabe können Sie zwischen der Bearbeitung im Rohformat und der Benutzeroberfläche wechseln, ohne Ihren Workflow oder Ihre Tools ändern zu müssen.
Dadurch sind Konfigurationen leichter lesbar, sicherer zu ändern und für das gesamte Team besser zugänglich, während sie vollständig in Ihre VS Code-Umgebung integriert bleiben.
ABHÄNGIGKEITEN WERDEN JETZT VOLLSTÄNDIG IN VS CODE ERKANNT
In 4D 21 R3 lädt die 4D-Analyzer-Erweiterung Projektabhängigkeiten auf die gleiche Weise wie 4D. Da Abhängigkeiten automatisch aufgelöst werden, stützen sich Syntaxprüfung und Code-Vervollständigung auf denselben Kontext wie die 4D-IDE, sodass das Feedback über alle Umgebungen hinweg konsistent bleibt.
Die Erweiterung liest Abhängigkeiten sowohl aus dependencies.json als auch aus environment4d.json. Komponenten, die von mehreren Projekten gemeinsam genutzt werden, werden ohne zusätzliche Konfiguration erkannt, und Aktualisierungen dieser Dateien lösen ein automatisches Neuladen des Projekts aus, sodass Änderungen sofort im Editor angezeigt werden.
Die GitHub-Integration folgt derselben Logik wie 4D. Komponenten werden über denselben lokalen Speicher heruntergeladen, wodurch Duplikate vermieden und die Versionen synchronisiert werden. Wenn in VS Code bereits eine GitHub-Sitzung aktiv ist, wird diese automatisch wiederverwendet. Ist dies nicht der Fall, kann eine Sitzung direkt über die Erweiterung geöffnet werden, um auf öffentliche und private Repositorys zuzugreifen, ohne den Arbeitsablauf zu unterbrechen.
VS Code hört auf zu raten. Es arbeitet mit denselben Abhängigkeiten, derselben Struktur und denselben Regeln wie Ihre 4D-Anwendung
Sicherheit
VERWENDEN SIE MACOS-KEYCHAIN-ZERTIFIKATE DIREKT IN HTTPS-ANFRAGEN
In 4D 21 R3 können HTTPS-Anfragen und HTTP-Agenten Zertifikate verwenden, die direkt im macOS-Schlüsselbund gespeichert sind.
Zertifikate werden beim Erstellen eines HTTPRequest oder eines HTTPAgent über die Eigenschaft storeCertificateName namentlich referenziert. 4D löst das Zertifikat über das Betriebssystem auf, und wenn das Zertifikat nicht gefunden wird, wird sofort ein Fehler zurückgegeben.
Dies folgt dem gleichen Ansatz, der bereits für den Windows-Zertifikatsspeicher verfügbar ist, sodass derselbe Code plattformübergreifend funktioniert.
Zertifikate müssen nicht mehr als Dateien innerhalb der Anwendungsumgebung verteilt oder gespeichert werden. Sie werden weiterhin vom System verwaltet, was die Bereitstellung vereinfacht und die konsistente Verwaltung von Anmeldedaten auf allen Rechnern gewährleistet.