Integrazione dell’IA
CENTRALIZZAZIONE DEI FORNITORI E DEI MODELLI DI IA CON ALIAS RIUTILIZZABILI
I fornitori e i modelli di IA sono ora definiti in una scheda dedicata all’IA nelle Impostazioni e riutilizzati in tutta l’applicazione.
Ogni fornitore memorizza il proprio URL di base, la chiave API e gli identificatori opzionali. Le connessioni possono essere testate direttamente, in modo che l’accesso venga verificato prima di effettuare qualsiasi chiamata. Una volta configurati, i fornitori diventano parte delle impostazioni del progetto e seguono la stessa logica di distribuzione nelle configurazioni a livello di struttura, utente o dati.
L’utilizzo dei modelli è semplificato grazie a due approcci. È possibile fare riferimento ai modelli utilizzando un formato basato sul provider, come ProviderName:ModelName, oppure definire alias di modelli che associano un nome personalizzato a un provider e a un ID modello. Quando l’attributo model corrisponde a un alias, 4D risolve automaticamente la configurazione del provider e del modello associati.
Ciò elimina la necessità di ripetere i dettagli del provider o gli identificatori dei modelli nel codice. Il cambio di provider, l’aggiornamento delle credenziali o la sostituzione dei modelli non richiedono modifiche in più metodi.
Le configurazioni dei provider e dei modelli rimangono accessibili in fase di esecuzione tramite la classe OpenAIProviders. È possibile ispezionare i provider disponibili, recuperare gli alias dei modelli o adattare il comportamento in modo dinamico quando necessario.
L’integrazione dell’IA diventa più facile da gestire man mano che si espande. La configurazione rimane centralizzata, l’utilizzo dei modelli rimane coerente e il codice rimane incentrato sulla logica dell’applicazione anziché sulla configurazione esterna.
Interfaccia utente
LOOK LIQUID GLASS PER I MODULI 4D SU macOS
In 4D 21 R3, i moduli su macOS adottano automaticamente lo stile di sistema Liquid Glass.
Gli oggetti standard come pulsanti, elenchi e menu seguono le impostazioni aggiornate di spaziatura, trasparenza e feedback visivo definite da macOS. Il rendering cambia visivamente, mentre la logica dei moduli e la gestione degli eventi rimangono invariate.
Poiché lo stile introduce trasparenza e forme arrotondate, i layout con spaziatura ridotta o elementi sovrapposti potrebbero richiedere lievi modifiche.
Le applicazioni si allineano alle attuali convenzioni di macOS senza modificare il modo in cui i moduli sono costruiti.
CREA INTERFACCE MODERNE CON FLUENT UI E LIQUID GLASS
In 4D 21 R3, la Libreria degli oggetti supporta Fluent UI su Windows e Liquid Glass su macOS.
I componenti esistenti vengono renderizzati utilizzando il sistema di progettazione selezionato senza modificarne la definizione. Gli stessi moduli si adattano su tutte le piattaforme, mantenendo un’interfaccia coerente e moderna senza necessità di riprogettazione.
I componenti aggiornati seguono le attuali pratiche di sviluppo, con metodi oggetto più puliti quando vengono aggiunti o rigenerati.
L’interfaccia si evolve su tutte le piattaforme mentre la struttura e la logica rimangono invariate.
STAMPA MODULI MODERNI CON RENDERING OTTIMIZZATO PER LA CARTA
In 4D 21 R3, i moduli che utilizzano stili di interfaccia utente moderni vengono automaticamente adattati per la stampa.
I widget vengono convertiti in rappresentazioni piatte e monocromatiche, mentre gli effetti visivi come la trasparenza e le ombre vengono rimossi. Il layout, l’allineamento e le dimensioni vengono preservati e i valori stampati corrispondono allo stato attuale, compresi i dati non salvati.
La trasformazione viene eseguita automaticamente e produce un output coerente su macOS e Windows, senza modifiche alla logica di stampa.
RETE
RETE LEGACY RIMOSSA
In 4D 21 R3, il livello di rete legacy è stato rimosso.
I nuovi progetti utilizzano QUIC per impostazione predefinita, mentre i database binari utilizzano ServerNet. Il livello di rete viene definito al momento della creazione in base al tipo di applicazione.
Le applicazioni esistenti che fanno ancora riferimento a Legacy rimangono compatibili. In fase di esecuzione, 4D utilizza ServerNet, quindi le applicazioni continuano a funzionare su un livello supportato senza richiedere modifiche immediate.
I protocolli supportati diventano lo standard, mentre Legacy non fa più parte della configurazione.
RICEVI EVENTI E-MAIL IN TEMPO REALE CON IMAP IDLE
In 4D 21 R3, IMAPTransporter supporta il protocollo IDLE, consentendo alle applicazioni di reagire alle modifiche della casella di posta non appena si verificano.
Il comando IMAP New transporter ora accetta un oggetto listener in cui è possibile definire funzioni di callback per eventi quali onMailCreated, onMailDeleted e onFlagsModified. Ogni callback riceve il transporter e un oggetto evento con dettagli quali il numero di messaggi, il numero di sequenza o i flag aggiornati.
Le notifiche sono controllate tramite la proprietà notifier. La chiamata a notifier.start() si abbona agli eventi del server, mentre notifier.stop() li mette in pausa. Quando è attivo, il transporter mantiene una connessione live e consegna gli eventi invece di affidarsi a un polling periodico.
Questo sposta la gestione delle email dai controlli programmati a un flusso guidato dagli eventi. Le applicazioni rimangono allineate allo stato della casella di posta, riducono le richieste non necessarie e possono aggiornare l’interfaccia utente o attivare la logica non appena si verificano dei cambiamenti.
4D Write Pro
STRUTTURARE I DOCUMENTI CON ELENCHI NUMERATI GERARCHICI
In 4D 21 R3, gli elenchi numerati in 4D Write Pro passano da una semplice formattazione a un’organizzazione strutturata dei documenti. Ora è possibile definire una numerazione gerarchica su più livelli, consentendo a sezioni, sottosezioni e contenuti nidificati di rimanere automaticamente coerenti.
La numerazione è definita tramite stili di paragrafo collegati, in cui ogni livello segue una gerarchia strutturata. Formati come 1, 1.1 e 1.1.1 vengono generati automaticamente.
Quando si aggiunge, si rimuove o si riorganizza il contenuto, la numerazione si aggiorna su tutti i livelli senza necessità di modifiche manuali.
Questo approccio elimina la necessità di ricominciare la numerazione o di gestirla tramite codice. La numerazione segue invece la struttura definita dall’utente, garantendo la coerenza in documenti lunghi o complessi.
Linguaggio 4D
Accedere alle sessioni utente direttamente dal 4D CLIENT
In 4D 21 R3, il comando Session è stato esteso al 4D client e ora restituisce l’oggetto della sessione remota invece dell’Null.
I dati della sessione, come l’ID della sessione, il nome utente e il contesto, diventano direttamente accessibili dal client 4D. Funzioni come createOTP(), getPrivileges(), hasPrivilege() e isGuest()possono essere chiamate localmente pur riflettendo la sessione del server.
Ciò elimina la necessità di riorganizzare il codice solo per accedere alle informazioni di sessione. La logica può rimanere dove viene utilizzata, il che rende i flussi più facili da seguire e riduce il numero di metodi intermedi richiesti nelle applicazioni client-server.
Anche gli scenari ibridi diventano più diretti. Un client può generare un OTP e aprire una pagina Qodly all’interno dello stesso contesto autenticato senza ulteriori coordinamenti.
Le restrizioni lato server rimangono invariate. Le funzioni di modifica dei privilegi continuano a essere eseguite solo sul server e l’archiviazione client rimane separata.
La gestione delle sessioni diventa più facile da integrare nel codice esistente senza doverlo ristrutturare in base al contesto di esecuzione.
ESEGUIRE FUNZIONI SHARED E SESSION SINGLETON SUL SERVER
In 4D 21 R3, le funzioni dei singleton condivisi e di sessione supportano la parola chiave ` server `, consentendo loro di essere eseguite sul server anche quando vengono chiamate da un 4D Client.
La funzione viene eseguita sull’istanza lato server del singleton. Se non esiste alcuna istanza, questa viene creata automaticamente, il che significa che un singleton può esistere sia sul client che sul server con valori di proprietà distinti.
Questo vale per le classi singleton condivise e di sessione. La parola chiave local può comunque essere utilizzata per chiarezza, mentre le funzioni del modello di dati ORDA accettano anche server per esplicitezza.
I parametri e i valori restituiti devono essere streamabili, seguendo lo stesso modello di esecuzione delle funzioni ORDA lato server.
La logica relativa alla sessione, le operazioni di memoria condivisa e l’elaborazione dipendente dal server possono ora rimanere all’interno del singleton che le definisce, senza essere spostate nei metodi di progetto o nelle funzioni ORDA per controllare la posizione di esecuzione.
Trasforma il testo dinamico in veri e propri metodi eseguibili
In 4D 21 R3, la nuova classe 4D.Method consente di eseguire come metodo nativo il codice memorizzato come testo.
Un metodo viene creato utilizzando 4D.Method.new() e si comporta come un metodo nativo. Può essere eseguito, memorizzato in oggetti o richiamato utilizzando call() e apply(). I parametri vengono passati in modo strutturato e This restituisce l’oggetto ospitante durante l’esecuzione.
Prima dell’esecuzione, checkSyntax() convalida il codice sorgente e restituisce informazioni dettagliate su errori e avvisi, inclusi i numeri di riga.
Ciò consente di introdurre logica dinamica senza sacrificare il controllo. Il codice memorizzato in database o fonti esterne può essere convalidato ed eseguito utilizzando lo stesso modello linguistico, il che rende la personalizzazione in fase di esecuzione più affidabile e più facile da mantenere.
L’esecuzione rimane coerente in tutti gli ambienti, poiché i metodi vengono eseguiti in modalità interpretata anche nelle applicazioni compilate.
Il comportamento dinamico si integra nell’applicazione invece di rimanere un meccanismo isolato.
CONVALIDA JSON CON GLI STANDARD MODERNI DI SCHEMA
In 4D 21 R3, il comando ` JSON Validate ` ora supporta l’ultimo standard JSON Schema (Draft 2020-12).
Gli schemi possono ora includere logica condizionale, vincoli avanzati e validazione estesa del formato. Ciò consente di esprimere più regole di validazione direttamente nello schema anziché implementarle nel codice.
Di conseguenza, la logica di convalida può essere condivisa tra i sistemi senza duplicazioni. I servizi backend, frontend ed esterni possono fare affidamento sullo stesso schema, il che mantiene il comportamento allineato mentre i dati fluiscono tra di essi.
La segnalazione degli errori è più precisa, rendendo più facile identificare e risolvere i problemi di convalida. Gli schemi Draft-04 esistenti continuano a essere supportati e il motore di convalida viene selezionato automaticamente in base all’attributo $schema.
CONVALIDA COERENTE DELLE DATE NEGLI SCHEMI JSON
In 4D 21 R3, JSON Validate gestisce le date in modo coerente, indipendentemente dal fatto che siano memorizzate come stringhe o come valori 4D Date nativi.
La convalida segue la definizione dello schema indipendentemente da come la data è rappresentata internamente. Ciò elimina le incongruenze quando i dati fluiscono tra JSON, API ed elaborazione interna.
Gli schemi rimangono il riferimento per le regole di convalida, senza richiedere una logica di conversione aggiuntiva prima della convalida.
RILEVA PRIMA GLI ERRORI DEI PARAMETRI DEI COMANDI NELL’EDITORE
In 4D 21 R3, il controllo della sintassi è stato esteso per convalidare i parametri dei comandi direttamente nell’editor, utilizzando i tipi e i modelli sintattici definiti nella documentazione.
Quando un comando richiede un tipo specifico come Text, Integer, Object, Pointer o una variabile assegnabile, gli argomenti non validi vengono ora rilevati durante la scrittura del codice, anziché emergere in un secondo momento in fase di esecuzione o durante il controllo sintattico. Ciò si applica anche ai parametri multitipo documentati, ai parametri variadici e ai gruppi di parametri variadici.
I controlli sono ora più precisi per casi comuni quali tipi di argomenti errati, valori non assegnabili passati dove è richiesta una variabile, o firme di comandi che dipendono da una sintassi specifica documentata. Il controllo della sintassi dei comandi esistente non viene qui sostituito. Viene esteso per coprire un insieme più ampio e preciso di regole relative ai parametri sia nell’editor di codice 4D che in VS Code.
Ciò avvicina l’utilizzo dei comandi a quanto effettivamente definito dalla documentazione, in modo che le chiamate non valide vengano identificate prima e corrette prima che si diffondano ulteriormente nel ciclo di sviluppo.
Componente 4D
GESTISCI LE DIPENDENZE DEI COMPONENTI GITLAB DALL’INTERFACCIA DEL PROGETTO
In 4D 21 R3, l’interfaccia Dipendenze del progetto ora supporta i repository GitLab, estendendo la gestione delle dipendenze esistente oltre GitHub.
I componenti possono essere aggiunti direttamente da un repository GitLab utilizzando un URL completo o un percorso del repository. I repository privati sono supportati tramite token di accesso personali, che possono essere definiti per ogni server e riutilizzati tra le dipendenze.
La selezione della versione segue la stessa logica degli altri componenti. Le dipendenze possono puntare alla versione più recente disponibile, a un tag specifico o a una versione semantica, consentendo un controllo preciso su ciò che viene integrato nel progetto.
Una volta aggiunti, i componenti GitLab si comportano come qualsiasi altra dipendenza. Sono elencati nell’interfaccia Dipendenze del progetto, vengono installati al riavvio del progetto e possono essere aggiornati, controllati o rimossi senza uscire dall’ambiente.
La gestione delle dipendenze diventa coerente tra le fonti del repository, quindi i componenti ospitati su GitLab seguono lo stesso ciclo di vita e le stesse regole di versioning del resto del progetto.
Estensione Visual Studio Code
MODIFICA RUOLI, PRIVILEGI E HANDLER HTTP IN MODO VISIVO IN VS CODE
I file di progetto strutturati possono ora essere modificati tramite editor UI dedicati direttamente in VS Code.
I ruoli e i privilegi, così come gli handler HTTP, si aprono in un’interfaccia visiva anziché in formato JSON grezzo. I campi sono organizzati, le opzioni sono esplicite e le configurazioni possono essere aggiornate senza dover navigare in strutture nidificate o gestire manualmente la sintassi.
La convalida è integrata. È più difficile introdurre configurazioni non valide e gli errori comuni causati dalla formattazione o dalla struttura vengono evitati prima che raggiungano il runtime.
Gli stessi file rimangono accessibili come testo in qualsiasi momento. È possibile passare dalla modifica in formato grezzo all’interfaccia utente a seconda dell’attività, senza modificare il flusso di lavoro o gli strumenti.
Ciò rende la configurazione più facile da leggere, più sicura da modificare e più accessibile a tutto il team, pur rimanendo completamente integrata nell’ambiente VS Code.
DIPENDENZE ORA COMPLETAMENTE RICONOSCIUTE IN VS CODE
In 4D 21 R3, l’estensione 4D-Analyzer carica le dipendenze del progetto allo stesso modo di 4D. Con le dipendenze risolte automaticamente, il controllo della sintassi e il completamento del codice si basano sullo stesso contesto dell’IDE 4D, quindi il feedback rimane coerente in tutti gli ambienti.
L’estensione legge le dipendenze sia da dependencies.json che da environment4d.json. I componenti condivisi tra più progetti vengono rilevati senza configurazione aggiuntiva e gli aggiornamenti a questi file attivano un ricaricamento automatico del progetto, in modo che le modifiche si riflettano immediatamente nell’editor.
L’integrazione con GitHub segue la stessa logica di 4D. I componenti vengono scaricati utilizzando la stessa memoria locale, evitando duplicazioni e mantenendo le versioni allineate. Quando una sessione GitHub è già attiva in VS Code, viene riutilizzata automaticamente. In caso contrario, è possibile aprire una sessione direttamente dall’estensione per accedere sia ai repository pubblici che a quelli privati senza interrompere il flusso di lavoro.
VS Code smette di tirare a indovinare. Funziona con le stesse dipendenze, la stessa struttura e le stesse regole della vostra applicazione 4D
sicurezza
UTILIZZA I CERTIFICATI DEL KEYCHAIN DI MACOS DIRETTAMENTE NELLE RICHIESTE HTTPS
In 4D 21 R3, le richieste HTTPS e gli agenti HTTP possono utilizzare certificati memorizzati direttamente nel Keychain di macOS.
I certificati vengono richiamati per nome utilizzando la proprietà storeCertificateName durante la creazione di un HTTPRequest o di un HTTPAgent. 4D risolve il certificato tramite il sistema operativo e, se il certificato non viene trovato, viene restituito immediatamente un errore.
Questo segue lo stesso approccio già disponibile per l’archivio certificati di Windows, consentendo allo stesso codice di funzionare su tutte le piattaforme.
I certificati non devono più essere distribuiti o archiviati come file all’interno dell’ambiente dell’applicazione. Rimangono gestiti dal sistema, il che semplifica la distribuzione e mantiene coerente la gestione delle credenziali su tutte le macchine.