Integración de la IA
CENTRALICE LOS PROVEEDORES Y MODELOS DE IA CON ALIAS REUTILIZABLES
Los proveedores y modelos de IA se definen ahora en una pestaña dedicada a la IA en las Propiedades y se reutilizan en toda la aplicación.
Cada proveedor almacena su URL base, su llave API y los identificadores opcionales. Las conexiones se pueden probar directamente, por lo que el acceso se verifica antes de realizar cualquier llamada. Una vez configurados, los proveedores pasan a formar parte de la configuración del proyecto y siguen la misma lógica de despliegue en las propiedades a nivel de estructura, usuario o datos.
El uso de modelos se simplifica mediante dos enfoques. Puede hacer referencia a los modelos utilizando un formato basado en el proveedor, como ProviderName:ModelName, o definir alias de modelos que asocien un nombre personalizado a un proveedor y un ID de modelo. Cuando el atributo model coincide con un alias, 4D resuelve automáticamente la configuración asociada del proveedor y del modelo.
Esto elimina la necesidad de repetir los detalles del proveedor o los identificadores de modelo en todo el código. Cambiar de proveedor, actualizar credenciales o sustituir modelos no requiere cambios en múltiples métodos.
Las configuraciones de proveedores y de modelos siguen siendo accesibles en tiempo de ejecución a través de la clase ` OpenAIProviders `. Puede inspeccionar los proveedores disponibles, recuperar alias de modelos o adaptar el comportamiento dinámicamente cuando sea necesario.
La integración de la IA se vuelve más fácil de gestionar a medida que se amplía. La configuración permanece centralizada, el uso de los modelos se mantiene coherente y el código se centra en la lógica de la aplicación en lugar de en la configuración externa.
Interfaz de usuario
STYLE LIQUID GLASS PARA FORMULARIOS 4D EN macOS
En 4D 21 R3, los formularios en macOS adoptan automáticamente el estilo del sistema Liquid Glass.
Los objetos estándar, como botones, listas y menús, siguen el espaciado, la transparencia y la retroalimentación visual actualizados definidos por macOS. El renderizado cambia visualmente, mientras que la lógica de los formularios y el manejo de eventos permanecen inalterados.
Dado que el estilo introduce transparencia y formas redondeadas, los diseños con espaciado reducido o elementos en capas pueden requerir pequeños ajustes.
Las aplicaciones se ajustan a las convenciones actuales de macOS sin cambiar la forma en que se crean los formularios.
CREE INTERFACES MODERNAS CON FLUENT UI Y LIQUID GLASS
En 4D 21 R3, la biblioteca de objetos es compatible con Fluent UI en Windows y Liquid Glass en macOS.
Los componentes existentes se representan utilizando el sistema de diseño seleccionado sin cambiar su definición. Los mismos formularios se adaptan a todas las plataformas, manteniendo una interfaz coherente y moderna sin necesidad de rediseñar.
Los componentes actualizados siguen las prácticas de desarrollo actuales, con métodos objeto más limpios al añadirlos o regenerarlos.
La interfaz evoluciona en todas las plataformas, mientras que la estructura y la lógica permanecen inalteradas.
IMPRIMA FORMULARIOS MODERNOS CON UN RENDERIZADO OPTIMIZADO
En 4D 21 R3, los formularios que utilizan estilos de interfaz de usuario modernos se adaptan automáticamente para la impresión.
Los widgets se convierten en representaciones planas y monocromáticas, y se eliminan los efectos visuales como la transparencia y las sombras. Se conservan el diseño, la alineación y las dimensiones, y los valores impresos coinciden con el estado actual, incluidos los datos no guardados.
La transformación se ejecuta automáticamente y produce un resultado coherente tanto en macOS como en Windows, sin cambios en la lógica de impresión.
RED
eliminación de la rED histórica
En 4D 21 R3, se ha eliminado la capa de red histórica.
Los nuevos proyectos utilizan QUIC de forma predeterminada, mientras que las bases de datos binarias utilizan ServerNet. La capa de red se define en el momento de la creación en función del tipo de aplicación.
Las aplicaciones existentes que aún hacen referencia a Legacy siguen siendo compatibles. En tiempo de ejecución, 4D utiliza ServerNet, por lo que las aplicaciones continúan ejecutándose en una capa compatible sin necesidad de cambios inmediatos.
Los protocolos compatibles pasan a ser la referencia, mientras que la capa histórica ya no forma parte de la configuración.
RECIBA EVENTOS DE CORREO ELECTRÓNICO EN TIEMPO REAL CON IMAP IDLE
En 4D 21 R3, IMAPTransporter es compatible con el protocolo IDLE, lo que permite a las aplicaciones reaccionar a los cambios en el buzón de correo a medida que se producen.
El comando «IMAP New transporter» ahora acepta un objeto listener en el que se pueden definir funciones de retrollamada para eventos como « onMailCreated », « onMailDeleted » y « onFlagsModified ». Cada retrollamada recibe el transportador y un objeto evento con detalles como el recuento de mensajes, el número de secuencia o los indicadores de actualización.
Las notificaciones se controlan a través de la propiedad notifier. Al llamar a notifier.start() se suscribe a los eventos del servidor, mientras que notifier.stop() los pausa. Cuando está activo, el transportador mantiene una conexión en tiempo real y entrega los eventos en lugar de depender de sondeos periódicos.
Esto cambia el manejo del correo electrónico de comprobaciones programadas a un flujo impulsado por eventos. Las aplicaciones se mantienen alineadas con el estado del buzón, reducen las solicitudes innecesarias y pueden actualizar la interfaz de usuario o activar la lógica tan pronto como se produzcan cambios.
4D Write Pro
ESTRUCTURAR LOS DOCUMENTOS CON LISTAS NUMERADAS JERÁRQUICAS
En 4D 21 R3, las listas numeradas de 4D Write Pro pasan de ser un simple formato a una organización estructurada de los documentos. Ahora puede definir una numeración jerárquica en varios niveles, lo que permite que las secciones, subsecciones y el contenido anidado mantengan la coherencia automáticamente.
La numeración se define mediante estilos de párrafo vinculados, donde cada nivel sigue una jerarquía estructurada. Formatos como 1, 1.1 y 1.1.1 se generan automáticamente.
Cuando se añade, elimina o reorganiza contenido, la numeración se actualiza en todos los niveles sin necesidad de ajustes manuales.
Este enfoque elimina la necesidad de reiniciar la numeración o mantenerla mediante código. En su lugar, la numeración sigue la estructura que defina, lo que garantiza la coherencia en documentos largos o complejos.
Lenguaje 4D
Acceda a las sesiones de usuario directamente desde UN CLIENTE 4D
En 4D 21 R3, el comando ` Session ` se ha ampliado al cliente 4D y ahora devuelve el objeto de sesión remota en lugar de ` Null`.
Se puede acceder directamente desde el cliente 4D a datos de la sesión como el ID de sesión, el nombre de usuario y el contexto. Funciones como createOTP(), getPrivileges(), hasPrivilege() y isGuest() se pueden invocar localmente sin dejar de reflejar la sesión del servidor.
Esto elimina la necesidad de reorganizar el código solo para acceder a la información de la sesión. La lógica puede permanecer donde se utiliza, lo que facilita el seguimiento de los flujos y reduce el número de métodos intermedios necesarios en las aplicaciones cliente-servidor.
Los escenarios híbridos también se vuelven más directos. Un cliente puede generar una OTP y abrir una página Qodly en el mismo contexto autenticado sin necesidad de coordinación adicional.
Las restricciones del lado del servidor permanecen sin cambios. Las funciones de modificación de privilegios siguen ejecutándose únicamente en el servidor, y el almacenamiento del cliente permanece separado.
La gestión de sesiones resulta más fácil de integrar en el código existente sin necesidad de reestructurarlo en torno al contexto de ejecución.
EJECUTAR FUNCIONES COMPARTIDAS y SESIÓN SINGLETON EN EL SERVIDOR
En 4D 21 R3, las funciones de singletons compartidas y de sesión admiten la palabra clave ` server `, lo que les permite ejecutarse en el servidor incluso cuando se invocan desde un cliente 4D.
La función se ejecuta en la instancia del lado del servidor del singleton. Si no existe ninguna instancia, se crea automáticamente, lo que significa que un singleton puede existir tanto en el cliente como en el servidor con valores de propiedad distintos.
Esto se aplica a las clases de singletons compartidos y de sesión. La palabra clave ` local ` puede seguir utilizándose para mayor claridad, mientras que las funciones del modelo de datos ORDA también aceptan ` server `.
Los parámetros y los valores devueltos deben ser transmisibles, siguiendo el mismo modelo de ejecución que las funciones ORDA del lado del servidor.
La lógica relacionada con la sesión, las operaciones de memoria compartida y el procesamiento dependiente del servidor ahora pueden permanecer dentro del singleton que los define, sin necesidad de trasladarlos a métodos proyecto o funciones ORDA para controlar la ubicación de ejecución.
Convierta texto dinámico en reales métodos ejecutables
En 4D 21 R3, la nueva clase ` 4D.Method ` permite que el código almacenado como texto se ejecute como un método nativo.
Un método se crea utilizando 4D.Method.new() y se comporta como un método nativo. Se puede ejecutar, almacenar en objetos o invocar utilizando call() y apply(). Los parámetros se pasan de forma estructurada, y This devuelve el objeto local durante la ejecución.
Antes de la ejecución, checkSyntax() valida el código fuente y devuelve información detallada sobre errores y advertencias, incluyendo los números de línea.
Esto permite introducir lógica dinámica sin sacrificar el control. El código almacenado en bases de datos o fuentes externas puede validarse y ejecutarse utilizando el mismo modelo de lenguaje, lo que hace que la personalización en tiempo de ejecución sea más fiable y fácil de mantener.
La ejecución se mantiene coherente en todos los entornos, ya que los métodos se ejecutan en modo interpretado incluso en aplicaciones compiladas.
El comportamiento dinámico se integra en la aplicación en lugar de permanecer como un mecanismo aislado.
VALIDAR JSON CON LOS ESTÁNDARES DE ESQUEMA MÁS MODERNOS
En 4D 21 R3, el comando « JSON Validate » ahora es compatible con el último estándar JSON Schema (Draft 2020-12).
Los esquemas ahora pueden incluir lógica condicional, restricciones avanzadas y validación de formato ampliada. Esto permite expresar más reglas de validación directamente en el esquema en lugar de implementarlas en el código.
Como resultado, la lógica de validación se puede compartir entre sistemas sin duplicación. Los servicios de backend, frontend y externos pueden basarse en el mismo esquema, lo que mantiene el comportamiento alineado a medida que los datos fluyen entre ellos.
Los informes de errores son más precisos, lo que facilita la identificación y corrección de los problemas de validación. Los esquemas Draft-04 existentes siguen siendo compatibles, y el motor de validación se selecciona automáticamente en función del atributo ` $schema `.
VALIDACIÓN COHERENTE DE FECHAS EN ESQUEMAS JSON
En 4D 21 R3, JSON Validate gestiona las fechas de forma coherente, independientemente de si se almacenan como cadenas o como valores 4D Date nativos.
La validación sigue la definición del esquema independientemente de cómo se represente la fecha internamente. Esto elimina las inconsistencias cuando los datos fluyen entre JSON, API y el procesamiento interno.
Los esquemas siguen siendo la referencia para las reglas de validación, sin necesidad de una lógica de conversión adicional antes de la validación.
DETECCIÓN DE ERRORES EN LOS PARÁMETROS DE LOS COMANDOS EN EL EDITOR
En 4D 21 R3, la verificación de sintaxis se amplía para validar los parámetros de los comandos directamente en el editor, utilizando los tipos y modelos sintácticos definidos en la documentación.
Cuando un comando espera un tipo específico, como Texto, Entero, Objeto, Puntero o una variable asignable, los argumentos no válidos se detectan ahora mientras se escribe el código, en lugar de aparecer más tarde en tiempo de ejecución o durante la verificación sintáctica. Esto también se aplica a los parámetros multitipo documentados, los parámetros variádicos y los grupos de parámetros variádicos.
Las verificaciones son ahora más precisas para casos comunes como tipos de argumentos incorrectos, valores no asignables pasados donde se requiere una variable, o firmas de comandos que dependen de una sintaxis específica documentada. La verificación de sintaxis de comandos existente no se sustituye aquí. Se amplía para cubrir un conjunto más amplio y exacto de reglas de parámetros tanto en el editor de código de 4D como en VS Code.
Esto acerca el uso de los comandos a lo que realmente define la documentación, de modo que las llamadas no válidas se identifican antes y se corrigen antes de que se extiendan más allá en el ciclo de desarrollo.
Componente 4D
GESTIONAR LAS DEPENDENCIAS DE LOS COMPONENTES GITLAB DESDE LA INTERFAZ DEL PROYECTO
En 4D 21 R3, la interfaz de dependencias del proyecto ahora es compatible con los repositorios GitLab, lo que amplía la gestión de dependencias existente más allá de GitHub.
Los componentes se pueden añadir directamente desde un repositorio GitLab utilizando una URL completa o una ruta de repositorio. Los repositorios privados son compatibles mediante tokens de acceso personales, que se pueden definir por servidor y reutilizar en todas las dependencias.
La selección de versiones sigue la misma lógica que otros componentes. Las dependencias pueden apuntar a la versión más reciente disponible, a una etiqueta específica o a una versión semántica, lo que permite un control preciso sobre lo que se integra en el proyecto.
Una vez añadidos, los componentes GitLab se comportan como cualquier otra dependencia. Aparecen en la interfaz de Dependencias del proyecto, se instalan al reiniciar el proyecto y se pueden actualizar, comprobar o eliminar sin salir del entorno.
La gestión de dependencias se vuelve coherente en todas las fuentes del repositorio, por lo que los componentes alojados en GitLab siguen el mismo ciclo de vida y las mismas reglas de versionado que el resto del proyecto.
Extensión Visual Studio Code
EDITE VISUALMENTE los ROLES, PRIVILEGIOS Y GESTORES HTTP EN VS CODE
Ahora se pueden editar archivos de proyecto estructurados a través de editores de interfaz de usuario específicos directamente en VS Code.
Los roles y privilegios, así como los controladores HTTP, se abren en una interfaz visual en lugar de en JSON sin formato. Los campos están organizados, las opciones son explícitas y las configuraciones se pueden actualizar sin tener que navegar por estructuras anidadas ni gestionar la sintaxis manualmente.
La validación está integrada. Es más difícil introducir configuraciones inválidas y se evitan los errores comunes causados por el formato o la estructura antes de que lleguen al tiempo de ejecución.
Se puede acceder a los mismos archivos como texto en cualquier momento. Puede alternar entre la edición sin formato y la interfaz de usuario según la tarea, sin cambiar su flujo de trabajo ni sus herramientas.
Esto hace que la configuración sea más fácil de leer, más segura de modificar y más accesible para todo el equipo, al tiempo que permanece totalmente integrada en su entorno VS Code.
LAS DEPENDENCIAS AHORA SE RECONOCEN PLENAMENTE EN VS CODE
En 4D 21 R3, la extensión 4D-Analyzer carga las dependencias del proyecto de la misma manera que 4D. Al resolverse las dependencias automáticamente, la verificación de sintaxis y la finalización de código se basan en el mismo contexto que el IDE 4D, por lo que la retroalimentación se mantiene coherente en todos los entornos.
La extensión lee las dependencias tanto de dependencies.json como de environment4d.json. Los componentes compartidos entre varios proyectos se detectan sin necesidad de configuración adicional, y las actualizaciones de estos archivos activan una recarga automática del proyecto, de modo que los cambios se reflejan inmediatamente en el editor.
La integración GitHub sigue la misma lógica que 4D. Los componentes se descargan utilizando el mismo almacenamiento local, lo que evita la duplicación y mantiene las versiones alineadas. Cuando ya hay una sesión GitHub activa en VS Code, se reutiliza automáticamente. Si no es así, se puede abrir una sesión directamente desde la extensión para acceder tanto a repositorios públicos como privados sin interrumpir el flujo de trabajo.
VS Code no hace más suposiciones. Funciona con las mismas dependencias, la misma estructura y las mismas reglas que su aplicación 4D
Seguridad
UTILICE LOS CERTIFICADOS DEL LLAVERO macOS DIRECTAMENTE EN LAS PETICIONES HTTPS
En 4D 21 R3, las peticiones HTTPS y los agentes HTTP pueden utilizar certificados almacenados directamente en el llavero macOS.
Los certificados se especifican por nombre utilizando la propiedad storeCertificateName al crear un HTTPRequest o un HTTPAgent. 4D resuelve el certificado a través del sistema operativo y, si no se encuentra, se devuelve un error inmediatamente.
Esta aproximación sigue el mismo enfoque ya disponible para el almacén de certificados Windows, lo que permite que el mismo código funcione en todas las plataformas.
Ya no es necesario distribuir ni almacenar los certificados como archivos en el entorno de la aplicación. El sistema se encarga de gestionarlos, lo que simplifica la implementación y mantiene la coherencia en el manejo de credenciales entre máquinas.