Intégration de l’IA
CENTRALISEZ LES FOURNISSEURS ET LES MODÈLES D’IA À L’AIDE D’ALIAS RÉUTILISABLES
Les fournisseurs et modèles d’IA sont désormais définis dans un onglet dédié à l’IA dans les Propriétés et réutilisés dans toute l’application.
Chaque fournisseur stocke son URL de base, sa clé API et des identifiants facultatifs. Les connexions peuvent être testées directement, ce qui permet de vérifier l’accès avant tout appel. Une fois configurés, les fournisseurs font partie des propriétés du projet et suivent la même logique de déploiement selon la configuration des propriétés structure, utilisateur ou utilisateur pour les données.
L’utilisation des modèles est simplifiée grâce à deux approches. Vous pouvez référencer les modèles à l’aide d’un format basé sur le fournisseur, ProviderName:ModelName, ou définir des alias de modèle qui associent un nom personnalisé à un fournisseur et à un identifiant de modèle. Lorsque l’attribut model correspond à un alias, 4D résout automatiquement la configuration associée du fournisseur et du modèle.
Cela évite d’avoir à répéter les détails du fournisseur ou les identifiants de modèle dans votre code. Changer de fournisseur, mettre à jour les identifiants ou remplacer des modèles ne nécessite pas de modifications dans vos méthodes.
Les configurations de fournisseurs et de modèles restent accessibles en exécution via la classe ` OpenAIProviders `. Vous pouvez lister les fournisseurs disponibles, récupérer les alias de modèles ou adapter le comportement de manière dynamique si nécessaire.
L’intégration de l’IA devient plus facile à gérer à mesure qu’elle évolue. La configuration est centralisée, l’utilisation des modèles reste cohérente et votre code reste axé sur la logique de l’application plutôt que sur la configuration externe.
Interface utilisateur
STYLE LIQUID GLASS POUR LES FORMULAIRES 4D SUR macOS
Dans 4D 21 R3, les formulaires sur macOS adoptent automatiquement le style système Liquid Glass.
Les objets standard tels que les boutons, les listes et les menus respectent les nouveaux espacements, la transparence et les retours visuels définis par macOS. L’apparence et le rendu sont modifiés mais la logique des formulaires et la gestion des événements restent inchangées.
Comme ce style introduit de la transparence et des formes arrondies, les mises en page avec un espacement serré ou des éléments superposés peuvent nécessiter des ajustements mineurs.
Les applications s’alignent sur les conventions actuelles de macOS sans modifier la façon dont les formulaires sont construits.
CRÉEZ DES INTERFACES MODERNES AVEC FLUENT UI ET LIQUID GLASS
Dans 4D 21 R3, la bibliothèque d’objets prend en charge Fluent UI sous Windows et Liquid Glass sous macOS.
Les composants existants s’affichent selon l’apparence système sélectionnée sans modification de leur définition. Les mêmes formulaires s’adaptent sur toutes les plateformes, garantissant une interface cohérente et moderne sans refonte.
Les composants mis à jour suivent les pratiques de développement actuelles, avec des méthodes objet plus épurées lorsqu’ils sont ajoutés ou régénérés.
L’interface évolue sur toutes les plateformes tandis que la structure et la logique restent inchangées.
IMPRIMEZ DES FORMULAIRES MODERNES AVEC UN RENDU OPTIMISÉ
Dans 4D 21 R3, les formulaires utilisant des styles d’interface utilisateur modernes sont automatiquement adaptés pour l’impression.
Les widgets sont convertis en représentations plates et monochromes, et les effets visuels tels que la transparence et les ombres sont supprimés. La mise en page, l’alignement et les dimensions sont conservés, et les valeurs imprimées correspondent à l’état courant, y compris les données non enregistrées.
La conversion s’effectue automatiquement et produit un résultat cohérent sur macOS et Windows, sans modification de la logique d’impression.
RÉSEAU
SUPPRESSION DU RÉSEAU HISTORIQUE
Dans 4D 21 R3, la couche réseau « historique » a été supprimée.
Les nouveaux projets utilisent QUIC par défaut, tandis que les bases de données binaires utilisent ServerNet. La couche réseau est définie au moment de la création en fonction du type d’application.
Les applications existantes qui font encore référence à au réseau historique restent compatibles. Lors de l’exécution, 4D utilise ServerNet, de sorte que les applications continuent de fonctionner sur une couche réseau valide sans nécessiter de modifications immédiates.
Les protocoles pris en charge sont utilisés par défaut, tandis que la couche historique ne fait plus partie de la configuration.
RECEVEZ DES ÉVÉNEMENTS E-MAIL EN TEMPS RÉEL AVEC IMAP IDLE
Dans 4D 21 R3, IMAPTransporter prend en charge le protocole IDLE, permettant aux applications de réagir aux modifications de la boîte aux lettres dès qu’elles se produisent.
La commande IMAP New transporter accepte désormais un objet listener dans lequel des fonctions de rappel peuvent être définies pour les événements onMailCreated, onMailDeleted et onFlagsModified. Chaque fonction de rappel reçoit le transporteur et un objet event contenant des détails tels que le nombre de messages, le numéro de séquence ou les indicateurs de mise à jour.
Les notifications sont contrôlées via la propriété notifier. L’appel de notifier.start() permet de s’abonner aux événements du serveur, tandis que notifier.stop() les met en pause. Lorsqu’il est actif, le transporteur maintient une connexion directe et transmet les événements au lieu de nécessiter des interrogations périodiques.
Cela fait passer la gestion des e-mails d’un système d’interrogations planifiées à un flux piloté par les événements. Les applications restent synchronisées avec l’état de la boîte de réception, réduisent les requêtes inutiles et peuvent mettre à jour l’interface utilisateur ou déclencher des actions dès que des changements surviennent.
4D Write Pro
STRUCTURER LES DOCUMENTS AVEC DES LISTES NUMÉROTÉES HIÉRARCHIQUES
Dans 4D 21 R3, les listes numérotées de 4D Write Pro passent d’un simple formatage à une organisation structurée des documents. Vous pouvez désormais définir une numérotation hiérarchique sur plusieurs niveaux, ce qui permet aux sections, sous-sections et contenus imbriqués de rester cohérents automatiquement.
La numérotation est définie via des styles de paragraphe liés, chaque niveau suivant une hiérarchie structurée. Des formats tels que 1, 1.1 et 1.1.1 sont générés automatiquement.
Lorsque du contenu est ajouté, supprimé ou réorganisé, la numérotation est mise à jour à tous les niveaux sans ajustement manuel.
Cette approche élimine la nécessité de redémarrer la numérotation ou de la gérer via du code. Au lieu de cela, la numérotation suit la structure que vous définissez, garantissant ainsi la cohérence dans les documents longs ou complexes.
Langage 4D
Accédez aux sessions utilisateur directement depuis un client 4D
Dans 4D 21 R3, la commande Session est étendue au client 4D et renvoie désormais l’objet de session à distance au lieu de Null.
Les données de session telles que l’ID de session, le nom d’utilisateur et le contexte deviennent directement accessibles depuis le client 4D. Des fonctions telles que createOTP(), getPrivileges(), hasPrivilege() et isGuest() peuvent être appelées localement tout en reflétant toujours la session serveur.
Il n’est donc plus nécessaire de réorganiser le code uniquement pour accéder aux informations de session. La logique applicative peut rester là où elle est utilisée, ce qui facilite le suivi des flux et réduit le nombre de méthodes intermédiaires requises dans les applications client-serveur.
Les scénarios hybrides deviennent également plus directs. Un client peut générer un mot de passe à usage unique (OTP) et ouvrir une page Qodly dans le même contexte authentifié sans coordination supplémentaire.
Les contrôles côté serveur restent inchangées. Les fonctions de modification des privilèges s’exécutent toujours uniquement sur le serveur, et le stockage client reste séparé.
La gestion des sessions devient plus facile à intégrer dans le code existant sans avoir à le restructurer en fonction du contexte d’exécution.
EXÉCUTER DES FONCTIONS SHARED ET SESSION SINGLETON SUR LE SERVEUR
Dans 4D 21 R3, les fonctions des singletons partagés et de session prennent en charge le mot-clé ` server `, ce qui leur permet de s’exécuter sur le serveur même lorsqu’elles sont appelées depuis un client 4D.
La fonction s’exécute sur l’instance côté serveur du singleton. Si aucune instance n’existe, elle est créée automatiquement, ce qui signifie qu’un singleton peut exister à la fois sur le client et sur le serveur avec des valeurs de propriétés distinctes.
Ceci s’applique aux classes de singletons partagés et de session. Le mot-clé local peut toujours être utilisé pour plus de clarté, de même les fonctions du modèle de données ORDA acceptent également server.
Les paramètres et les valeurs renvoyées doivent être streamable, suivant le même principe que les fonctions ORDA côté serveur.
La logique liée à la session, les opérations en mémoire partagée et le traitement dépendant du serveur peuvent désormais rester à l’intérieur du singleton qui les définit, sans être déplacés vers des méthodes projet ou des fonctions ORDA pour contrôler l’emplacement d’exécution.
Transformez du texte dynamique en véritables méthodes exécutables
Dans 4D 21 R3, la nouvelle classe 4D.Method permet d’exécuter du code stocké sous forme de texte en tant que méthode native.
Une méthode est créée à l’aide de ` 4D.Method.new() ` et se comporte comme une méthode native. Elle peut être exécutée, stockée dans des objets ou invoquée à l’aide de ` call() ` et ` apply()`. Les paramètres sont passés de manière structurée, et ` This ` renvoie l’objet hôte pendant l’exécution.
Avant l’exécution, checkSyntax() valide le code source et renvoie des informations détaillées sur les erreurs et les warnings, incluant les numéros de ligne.
Cela permet d’introduire une logique dynamique sans sacrifier le contrôle. Le code stocké dans des bases de données ou des sources externes peut être validé et exécuté à l’aide du même modèle de langage, ce qui rend la personnalisation plus fiable et plus facile à maintenir.
L’exécution reste cohérente d’un environnement à l’autre, car les méthodes s’exécutent en mode interprété même dans les applications compilées.
Le comportement dynamique s’intègre à l’application au lieu de rester un mécanisme isolé.
VALIDER LE JSON AVEC LES NORMES DE SCHÉMA MODERNES
Dans 4D 21 R3, la commande ` JSON Validate ` prend en charge la dernière norme JSON Schema (Draft 2020-12).
Les schémas peuvent désormais inclure une logique conditionnelle, des contraintes avancées et une validation de format étendue. Cela permet d’exprimer davantage de règles de validation directement dans le schéma plutôt que de les implémenter dans le code.
Par conséquent, la logique de validation peut être partagée entre les systèmes sans duplication. Les services backend, frontend et externes peuvent s’appuyer sur le même schéma, ce qui garantit la cohérence du comportement lors des flux de données entre eux.
Le signalement des erreurs est plus précis, ce qui facilite l’identification et la correction des problèmes de validation. Les schémas Draft-04 existants restent pris en charge, et le moteur de validation est sélectionné automatiquement en fonction de l’attribut ` $schema `.
VALIDATION COHÉRENTE DES DATES DANS LES SCHÉMAS JSON
Dans 4D 21 R3, JSON Validate gère les dates de manière cohérente, qu’elles soient stockées sous forme de chaînes de caractères ou de valeurs 4D Date natives.
La validation suit la définition du schéma, quelle que soit la manière dont la date est représentée en interne. Cela élimine les incohérences lors des flux de données entre JSON, les API et le traitement interne.
Les schémas restent la référence pour les règles de validation, sans nécessiter de logique de conversion supplémentaire avant la validation.
DÉTECTION PLUS TÔT DES ERREURS DE PARAMÈTRES DE COMMANDE DANS L’ÉDITEUR
Dans 4D 21 R3, la vérification syntaxique est étendue pour valider les paramètres de commande directement dans l’éditeur, en utilisant les types et les modèles syntaxiques définis dans la documentation.
Lorsqu’une commande attend un type spécifique tel que Text, Integer, Object, Pointer ou une variable assignable, les arguments non valides sont désormais détectés lors de l’écriture du code, au lieu d’apparaître plus tard lors de l’exécution ou pendant la vérification de syntaxe. Cela s’applique également aux paramètres multitypes documentés, aux paramètres variadiques et aux groupes de paramètres variadiques.
Les vérifications sont désormais plus précises pour les cas courants tels que les types d’arguments erronés, les valeurs non assignables passées là où une variable est requise, ou les signatures de commande qui dépendent d’une syntaxe documentée spécifique. La vérification de syntaxe des commandes existante n’est pas remplacée ici. Elle est étendue pour couvrir un ensemble plus large et plus précis de règles de paramètres à la fois dans l’éditeur de code 4D et dans VS Code.
Cela rapproche l’utilisation des commandes de ce que la documentation définit réellement, de sorte que les appels non valides sont identifiés plus tôt et corrigés avant qu’ils ne se produisent plus loin dans le cycle de développement.
Composant 4D
GÉRER LES DÉPENDANCES DES COMPOSANTS GITLAB À PARTIR DE L’INTERFACE DU PROJET
Dans 4D 21 R3, l’interface Dépendances du projet prend désormais en charge les dépôts GitLab, étendant ainsi la gestion existante des dépendances via GitHub.
Les composants peuvent être ajoutés directement à partir d’un dépôt GitLab en utilisant soit une URL complète, soit un chemin d’accès au dépôt. Les dépôts privés sont pris en charge via des tokens d’accès personnels, qui peuvent être définis par serveur et réutilisés entre les dépendances.
La sélection de version suit la même logique que pour les autres composants. Les dépendances peuvent cibler la version la plus récente disponible, une balise spécifique ou une version sémantique, ce qui permet un contrôle précis sur ce qui est intégré au projet.
Une fois ajoutés, les composants GitLab se comportent comme n’importe quelle autre dépendance. Ils sont répertoriés dans l’interface « Dépendances du projet », installés au redémarrage du projet, et peuvent être mis à jour, vérifiés ou supprimés sans quitter l’environnement.
La gestion des dépendances devient cohérente entre les différentes sources du référentiel, de sorte que les composants hébergés sur GitLab suivent le même cycle de vie et les mêmes règles de gestion des versions que le reste du projet.
Extension Visual Studio Code
MODIFIEZ VISUELLEMENT LES RÔLES, LES PRIVILÈGES ET LES GESTIONNAIRES HTTP DANS VS CODE
Les fichiers de projet structurés peuvent désormais être modifiés via des éditeurs d’interface utilisateur dédiés directement dans VS Code.
Les rôles et privilèges, ainsi que les gestionnaires HTTP, s’ouvrent dans une interface visuelle plutôt que sous forme de JSON brut. Les champs sont organisés, les options sont explicites et les configurations peuvent être mises à jour sans avoir à naviguer dans des structures imbriquées ni à gérer la syntaxe manuellement.
La validation est intégrée. Il est plus difficile d’introduire des configurations invalides, et les erreurs courantes causées par le formatage ou la structure sont évitées avant qu’elles n’atteignent l’exécution.
Les mêmes fichiers restent accessibles au format texte à tout moment. Vous pouvez basculer entre l’édition brute et l’interface utilisateur en fonction de la tâche, sans modifier votre flux de travail ni vos outils.
Cela rend la configuration plus facile à lire, plus sûre à modifier et plus accessible à l’ensemble de l’équipe, tout en restant entièrement intégrée à votre environnement VS Code.
LES DÉPENDANCES SONT DÉSORMAIS ENTIÈREMENT RECONNUES DANS VS CODE
Dans 4D 21 R3, l’extension 4D-Analyzer charge les dépendances du projet de la même manière que 4D. Les dépendances étant résolues automatiquement, la vérification syntaxique et la complétion de code s’appuient sur le même contexte que l’IDE 4D, ce qui garantit une cohérence du retour d’information entre les environnements.
L’extension lit les dépendances à partir des fichiers dependencies.json et environment4d.json. Les composants partagés entre plusieurs projets sont détectés sans configuration supplémentaire, et les mises à jour de ces fichiers déclenchent un rechargement automatique du projet afin que les modifications soient immédiatement répercutées dans l’éditeur.
L’intégration GitHub suit la même logique que 4D. Les composants sont téléchargés en utilisant le même stockage local, ce qui évite les doublons et assure la cohérence des versions. Lorsqu’une session GitHub est déjà active dans VS Code, elle est réutilisée automatiquement. Si ce n’est pas le cas, une session peut être ouverte directement depuis l’extension pour accéder aux dépôts publics et privés sans interrompre le flux de travail.
VS Code ne fait plus de suppositions. Il fonctionne avec les mêmes dépendances, la même structure et les mêmes règles que votre application 4D
sécurité
UTILISEZ LES CERTIFICATS DU TROUSSEAU MACOS DIRECTEMENT DANS LES REQUÊTES HTTPS
Dans 4D 21 R3, les requêtes HTTPS et les agents HTTP peuvent utiliser des certificats stockés directement dans le trousseau macOS.
Les certificats sont référencés par leur nom à l’aide de la propriété storeCertificateName lors de la création d’un HTTPRequest ou d’un HTTPAgent. 4D résout le certificat via le système d’exploitation, et si le certificat est introuvable, une erreur est immédiatement renvoyée.
Cette approche est identique à celle déjà disponible pour le magasin de certificats Windows, ce qui permet au même code de fonctionner sur toutes les plateformes.
Les certificats n’ont plus besoin d’être distribués ou stockés sous forme de fichiers au sein de l’environnement de l’application. Ils restent gérés par le système, ce qui simplifie le déploiement et assure la cohérence de la gestion des identifiants d’une machine à l’autre.