martedì 3 novembre 2026

Free VueLityX© 1.0.0.100 il nuovo editor di style e animazioni GSAP - in arrivo a breve

Free VueLityX© 1.0.0.100 : il nuovo editor di style e animazioni GSAP - in arrivo a breve

POSTED BY GIULIANO PAGNINI, 03 NOV 2026

Free download https://vuelityx.com/

https://pgsoft.it/plyxhtml/

https://pgsoft.it

New!! Nuovi Componenti spettacolari
New!! Filtri per categoria

New!! Organizzazione dei componenti per Template/progetto

Nuovissimo Style Editor super professionale!!

Animazioni da professionisti, senza scrivere una riga di GSAP

VueLityX ha un nuovo editor di animazioni: crei animazioni GSAP cliccando sugli elementi della tua app Vue o Nuxt, le vedi girare nell'anteprima reale e le salvi nel progetto senza toccare i file .vue.

È pensato per chi costruisce siti e applicazioni con Vue e vuole movimento di qualità — titoli che entrano lettera per lettera, sezioni che si rivelano allo scroll, transizioni fra le pagine — senza passare ore fra documentazione, timeline scritte a mano e prove nel browser. Chi conosce già GSAP ritrova i suoi concetti (timeline, ease, stagger, keyframe, ScrollTrigger); chi non lo conosce può lavorare tutto in modo visuale.

In questo articolo vediamo cosa c'è dentro: la timeline, il Graph Editor con le curve Bezier, la libreria dei preset, le Scene per coordinare più viste e le transizioni fra pagine, e tutto il lavoro fatto per renderlo affidabile.

Come funziona: tre pezzi che lavorano insieme

L'editor scrive un file di descrizione, e un piccolo runtime lo esegue nella tua app: il codice dei componenti resta com'è.

L'editor. Si apre accanto all'anteprima della tua app in VueLityX. Premi “Seleziona elemento”, clicchi un titolo o un'immagine nell'anteprima e l'editor crea il passo di animazione con il selettore giusto. Ogni modifica si vede subito sull'app vera, non su un modello.
Il descrittore. Ogni animazione è un file src/animations/<nome>.anim.json: passi, tempi, ease, keyframe, varianti per mobile e tablet, elementi aggiunti. È leggibile, si versiona con git e si confronta facilmente.
Il runtime. Al primo salvataggio VueLityX installa useVxAnimation.js nel progetto e lo aggancia a main.js (o ai plugin di Nuxt). Da quel momento ogni animazione parte da sola quando la sua vista viene montata. GSAP e i descrittori si caricano solo quando servono, vista per vista, quindi il bundle principale non cresce.

Se preferisci il controllo manuale, puoi anche usare il composable direttamente in un componente (useVxAnimation(descrittore, root)) o con <Transition> di Vue tramite vxTransition. E se l'animazione deve vivere fuori da Vue, l'export la trasforma in GSAP puro, in un hook React, in un frammento HTML o in CSS @keyframes.

Una timeline da editor video

Ogni passo è una barra sulla timeline: la trascini per spostarla, ne tiri il bordo per cambiarne la durata, e i rombi ◆ sono i keyframe.

Zoom fino a 64x, ancorato al punto sotto il mouse (Ctrl+rotella), con i tasti + e −, e “⤢ Selezione” (tasto Z) per inquadrare solo i passi selezionati. Maiusc+rotella scorre in orizzontale.
Snapping ai bordi degli altri passi, ai keyframe, ai marker, alla testina e alla griglia, anche a 24, 30 o 60 fotogrammi al secondo. Una guida mostra a cosa si sta agganciando; Alt lo disattiva al volo.
Keyframe inseriti alla posizione della testina (tasto K), con i valori già interpolati.
Marker e regione di loop: doppio clic sul righello per un marker, Maiusc+trascina per ripetere solo un pezzo in anteprima.
Copia, incolla e duplica (Ctrl+C / V / D), anche di gruppi di passi o di keyframe.

Selezione multipla

Con Ctrl+clic, Maiusc+clic o un riquadro selezioni più passi insieme, e il pannello a destra diventa una modifica comune. Durata, delay, stagger, ease, ripetizioni e yoyo si cambiano per tutti in un colpo; dove i valori sono diversi il campo dice “misti” e resta vuoto finché non scrivi un valore.

Ci sono anche gli strumenti per i tempi che di solito si fanno a mano:

Allinea inizi o allinea fine;
In sequenza, uno dopo l'altro con un intervallo (negativo per sovrapporli);
A cascata, con partenze sfalsate di un tempo fisso;
Durata del primo applicata a tutti.

I calcoli usano la stessa timeline di GSAP dell'export, quindi il risultato è esatto anche con posizioni relative come < o +=0.5. Ogni comando è una sola voce dello storico: un Ctrl+Z e torni indietro.

Graph Editor: la curva del movimento, a mano

Il Graph Editor (pulsante “📈 Grafico” o tasto G) mostra come cambia ogni proprietà nel tempo, e ti lascia modellare la curva direttamente.

Scegli la proprietà dalle etichette in alto (opacity, y, scale…) e vedi i suoi punti: l'inizio, ogni keyframe, la fine. Trascinando un punto in verticale cambi il valore, in orizzontale il tempo; Maiusc blocca un asse, Alt toglie lo snap. Un punto vuoto è un valore implicito (quello attuale dell'elemento): basta trascinarlo per renderlo esplicito.

Cliccando su un tratto compaiono le due maniglie Bezier della sua ease. Se il passo usa un nome di GSAP come power2.out, le maniglie tratteggiate ne mostrano l'approssimazione; al primo trascinamento la curva diventa una cubic-bezier(...) personalizzata, che vale identica anche nell'export CSS. Per partire velocemente ci sono le curve rapide: lineare, entrata, uscita, entrata-uscita, rimbalzo indietro, elastica.

Un doppio clic sulla curva aggiunge un keyframe in quel punto. Tutto si può fare anche da tastiera: le frecce spostano il punto o la maniglia selezionata, Maiusc fa il passo grande. E ogni trascinamento è una sola voce dello storico.

Libreria preset: si guarda, si sceglie, si applica

La libreria (“▦ Libreria”) raccoglie tutti i preset in schede con un'anteprima animata: passi sopra una scheda e la vedi muoversi.

I preset sono divisi per categoria — entrata, uscita, testo, cascata, enfasi, interazione (hover e clic), SVG — con una ricerca e i ★ preferiti. “Applica” lavora sul passo selezionato o su tutti i passi della selezione multipla, in un'unica voce dello storico.

I preset che crei tu possono stare in due posti:

I miei: valgono in tutti i tuoi progetti, su questo PC.
Progetto: stanno in .vuelityx/presets.json dentro il progetto, quindi viaggiano con git e chi lavora con te li ritrova.

Salvando più passi insieme ottieni una sequenza: i passi con i loro tempi relativi. Se la applichi a tanti passi quanti ne contiene, ne riprende movimento e tempi lasciando i tuoi bersagli; altrimenti aggiunge i suoi passi alla posizione della testina. Per passare i preset da un PC all'altro c'è l'esportazione e l'importazione in JSON.

Scene: più viste in sequenza e transizioni fra pagine

Una scena coordina le animazioni di più viste e anima il passaggio da una pagina all'altra, senza modificare App.vue né il router. Si apre con “🎬 Scene” e si salva in src/animations/<nome>.scene.json.

Sequenza di viste

Una pagina è fatta di più componenti: header, hero, sezioni. Con la sequenza decidi chi parte quando: subito, oppure quando un'altra vista inizia o finisce, più uno scarto in secondi (anche negativo, per sovrapporle). Per esempio: l'header entra, l'hero parte 0,2 secondi prima che l'header finisca, le sezioni 0,4 secondi dopo l'inizio dell'hero.

Una vista che aspetta applica subito il suo stato iniziale, quindi non c'è nessun “flash” mentre attende. Se la vista che aspetta non è nella pagina, parte subito. L'editor mostra le barre con i tempi stimati dalle animazioni salvate e segnala i problemi, come i cicli o le viste ripetute.

Transizioni fra pagine

Le transizioni sono regole “da → a”: vale la prima che corrisponde. Da e a possono essere * (tutte), un percorso con * e ** (/blog/**), il nome di una route o di un componente.

Tipo	Cosa succede
Dissolvenza	la pagina vecchia sfuma, la nuova compare
Scorrimento	le pagine scorrono nella direzione scelta
Zoom	leggero zoom in uscita e in entrata
Tendina	un pannello colorato copre e poi scopre lo schermo
Colore pieno	lo schermo sfuma su un colore e poi riappare
Personalizzata	le proprietà GSAP che scegli per uscita ed entrata
Nessuna	un'eccezione a una regola più generale

Di default le animazioni della pagina nuova partono a transizione finita, così con la tendina non girano coperte. Se un'altra guardia del router annulla la navigazione, la pagina torna com'era; e un tempo massimo garantisce che la navigazione non resti mai bloccata.

Nell'editor ogni transizione ha un'anteprima su due pagine finte, e “▶ Prova” la esegue nell'app vera, senza salvare. In Nuxt basta lasciare spenta la pageTransition di Nuxt, per non sommare due transizioni.

Gli strumenti di creazione

Oltre a timeline, grafico e preset, l'editor ha gli strumenti per i casi che di solito richiedono codice.

Avvio dell'animazione: al caricamento della vista, quando l'elemento entra nello schermo, al passaggio del mouse (anche col focus da tastiera), al clic, al focus, o legata a uno stato del componente. Oppure collegata allo scroll con ScrollTrigger (scrub e pin).
Responsive: ogni passo può avere valori diversi per desktop, tablet e mobile, o essere spento su una larghezza. Nell'app la timeline si ricostruisce quando si passa da una soglia all'altra.
Testo diviso in caratteri, parole o righe, per gli effetti a cascata sui titoli.
Elementi aggiunti: immagini, box e testi inseriti nella vista a runtime, senza toccare il .vue. Le immagini si scelgono dal disco: VueLityX le copia in public/img e scrive il percorso img/nome.jpg.
Motion Path: disegni il percorso cliccando i punti direttamente sulla pagina, e l'elemento lo segue.
SVG: disegno del tratto (DrawSVG) e trasformazione da una forma all'altra (MorphSVG), con i plugin che il progetto ha davvero installato.
Mini-wizard CSS: bordo, ombra, ombra del testo, padding, margine, raggio, filtri e origine si compongono scegliendo i pezzi, invece di scrivere 1px solid #fff a memoria.
Target stabili: l'editor ricorda un'impronta di ogni elemento (tag, classi, testo), così, se dopo una modifica al componente il selettore non trova più l'elemento, può ritrovarlo dall'impronta.
Export: GSAP puro (modulo ES), hook React, frammento HTML con GSAP da CDN, oppure CSS @keyframes per chi non vuole caricare JavaScript.

Fatto per non perdere lavoro

Un editor professionale si giudica anche da quello che non succede: file rovinati, modifiche perse, elementi che lampeggiano.

Salvataggio sicuro. Ogni file si scrive prima in una copia temporanea e poi si sostituisce in un colpo solo: un'interruzione a metà non lascia mai un file rotto. La versione precedente finisce nello storico locale del progetto (.vuelityx/history, le ultime 30). Se il file è stato modificato fuori dall'editor — da VS Code, da git, da un collega — l'editor se ne accorge e chiede cosa fare invece di sovrascrivere.
Formato versionato. Ogni descrittore porta il suo numero di formato (schemaVersion): i file vecchi vengono aggiornati in automatico all'apertura.
Annulla e ripeti affidabili. Ogni gesto è una voce (un campo, un trascinamento, un comando), e annullando torna anche la selezione sul passo toccato. Il pulsante ▾ apre l'elenco delle modifiche: un clic e torni a quel punto; 💾 segna lo stato salvato. Lo storico è stato messo alla prova con lunghe serie di modifiche casuali, annullate e ripetute fino a tornare esattamente allo stato di partenza.
Niente flash. Un elemento che deve entrare in dissolvenza è già nascosto al primo disegno della pagina, anche nell'HTML generato dal server con Nuxt. Se qualcosa va storto, un paracadute lo rende comunque visibile dopo 3 secondi.
Movimento ridotto. Se il sistema chiede meno movimento, l'animazione salta allo stato finale o tiene solo la dissolvenza, a tua scelta. L'anteprima ti fa vedere come appare.
Prestazioni. L'editor segnala le proprietà che costano a ogni fotogramma (larghezza, margini, ombre) e suggerisce l'alternativa che scorre sulla GPU.
Diagnostica. Target non trovati, selettori sbagliati o plugin mancanti compaiono nel pannello di diagnostica e, in sviluppo, nella console. Nella console dell'anteprima __vxDiag() mostra versione del runtime, viste montate, scene e ultimi errori.
Accessibilità e lingue. L'editor si usa da tastiera ed è compatibile con i lettori di schermo; segue la lingua di VueLityX. Per chi usa TypeScript il runtime ha i suoi tipi.

Editor dei giochi:

VueLityX ha un editor dei giochi: costruisci livelli 3D piazzando modelli, luci e zone con il mouse, premi “Prova” e ci giochi subito nel browser, dentro il tuo progetto Vue.

Un gioco nel browser disegna tutto dentro un <canvas>: personaggi, alberi e case non sono componenti che un designer può selezionare. Per questo l'editor dei giochi lavora in modo diverso dal designer delle viste: il livello è un dato, un file JSON che descrive terreno, oggetti, luci e regole; il motore lo legge; l'editor lo modifica. Il codice del gioco resta fisso, cambiano i livelli.

Il motore è Babylon.js, con materiali realistici (PBR), ombre, ambiente HDR e bagliori. Menu, punteggio e messaggi a schermo sono invece normali componenti Vue, sopra la scena 3D.

Come funziona

Tutto parte dal Game Kit, che VueLityX installa nel progetto con un clic, e da un editor che usa lo stesso motore del gioco: quello che vedi nell'editor è quello che giochi.

Il Game Kit. Dal menu “Aggiungi Game Kit…” (o aprendo l'editor in un progetto che non lo ha) VueLityX mostra prima l'elenco delle modifiche, poi copia i file del gioco, aggiunge a package.json solo i pacchetti mancanti ed esegue npm install. Non tocca i tuoi file, né il router né App.vue: il gioco ha una sua pagina, gioco.html. L'installazione è “tutto o niente”: se qualcosa va storto a metà, il progetto torna com'era.
L'editor. È una pagina web del progetto (game-editor.html, in Vue con Babylon.js) che VueLityX apre nella sua finestra. Se il dev server non è acceso, lo avvia e aspetta che sia pronto.
Le scene. Ogni livello è un file public/game/scenes/<nome>.json. Il salvataggio lo fa VueLityX: controlla che il JSON sia valido, scrive solo in quella cartella e tiene una copia .bak della versione precedente.

Per ora il Game Kit si installa nei progetti Vite + Vue; con Nuxt VueLityX lo dice chiaramente invece di procedere.

L'editor: tre pannelli e una vista 3D

L'editor è organizzato come gli strumenti professionali: a sinistra cosa c'è nella scena, al centro la scena, a destra le proprietà di quello che hai selezionato.

A sinistra, la gerarchia e la libreria. La gerarchia elenca ambiente, terreno, giocatore, oggetti, gemme, luci, zone e i gruppi di alberi e rocce. La libreria mostra i modelli con le loro miniature: ne piazzi uno con un clic sul terreno oppure trascinandolo nella vista.
Al centro, la vista 3D. Clic per selezionare; maniglie per spostare, ruotare e scalare; aggancio alla griglia; collisioni visibili; tasto F per inquadrare l'oggetto selezionato.
A destra, le proprietà, con anteprima dal vivo. Posizione, rotazione, scala e tipo di collisione di un oggetto; sole, nebbia ed esposizione dell'ambiente; colline e piazza del terreno; quantità e distanze degli oggetti sparsi, come boschi e rocce.

I comandi sono quelli che ci si aspetta: annulla e ripeti con tutta la cronologia (Ctrl+Z / Ctrl+Y), duplica, elimina, salva (Ctrl+S) e “salva con nome” per creare nuovi livelli partendo da uno esistente. Il pulsante Prova salva e apre il gioco su quel livello; dal gioco, un pulsante riporta all'editor.

Modelli, luci e ambiente

La grafica di un gioco professionale nasce in strumenti come Blender: l'editor non prova a sostituirli, ma rende semplice portarne il lavoro nel livello.

Importare modelli

Nella libreria c'è il pulsante Importa. In VueLityX apre la finestra “Apri” di Windows per i file .glb e .gltf, il formato 3D standard del web che si esporta direttamente da Blender con materiali e animazioni. I file vengono copiati in public/game/models:

un .gltf viene copiato insieme ai suoi file .bin e alle texture, mantenendo le sottocartelle;
se il nome è già usato, il nuovo modello diventa per esempio “inn2”;
un .gltf senza i suoi file, un riferimento che punta fuori dalla cartella o un formato diverso vengono rifiutati con un messaggio chiaro.

I modelli importati compaiono subito nella libreria, con la loro miniatura, e si piazzano come gli altri.

Luci

Le luci puntiformi si piazzano dalla libreria e si spostano con le maniglie, come gli oggetti. Di ognuna si regolano altezza, colore, intensità e portata, più due effetti che fanno subito atmosfera: la fiamma, un tremolio come quello di una lanterna, e il bagliore, il punto luminoso visibile. Per lavorare sulle scene notturne c'è la “Luce di lavoro”, che illumina l'editor senza cambiare il gioco.

Ambiente e terreno

Sole, nebbia ed esposizione regolano la luce generale della scena, sopra un cielo HDR. Il terreno ha colline e una piazza regolabili, e i gruppi di oggetti sparsi riempiono il paesaggio di alberi e rocce scegliendo solo quantità e distanze.

Zone: un po' di logica di gioco, senza codice

Le zone sono aree invisibili della scena che fanno succedere qualcosa quando il giocatore ci entra. Bastano tre tipi per costruire livelli con un obiettivo e qualche sorpresa.

Zona	Cosa fa
Messaggio	mostra un testo a schermo, anche una sola volta
Uscita	è il punto in cui si vince; se servono tutte le gemme e ne mancano, dice quante
Teletrasporto	porta il giocatore altrove, con scintille e un suono

La destinazione di un teletrasporto si sceglie con un clic nella vista o trascinando il suo segnaposto. Se la scena ha un'uscita, raccogliere l'ultima gemma non chiude la partita: compare “Raggiungi «Arco del villaggio»” e la bussola punta lì.

Affidabilità e sicurezza

Un editor che gira su schede grafiche e configurazioni diverse deve prima di tutto aprirsi sempre, e non deve mai mettere a rischio il progetto.

Motore a versione fissa. Babylon.js è incluso nel kit come un unico file già pronto, con tutti gli shader. Non dipende da come il dev server riorganizza i pacchetti npm, quindi non ci sono due copie del motore né versioni diverse da progetto a progetto.
Caricamento che non si blocca. La scena inizia a disegnarsi subito e l'attesa dei materiali ha un limite. Se qualcosa non è pronto, l'editor si apre comunque e lo segnala; se mancano dei file si ricarica da solo una volta.
Diagnostica copiabile. Se la scena non parte, un riquadro mostra scheda grafica, shader e file mancanti, con i pulsanti “Copia diagnostica” e “Ricarica”: un testo da mandare a chi dà assistenza, invece di uno schermo grigio.
Scene versionate. Ogni scena porta il suo tipo e la sua versione. All'apertura una scena vecchia viene aggiornata, e gli elementi inutilizzabili (coordinate non valide, modelli assenti, raggi negativi) vengono tolti con un avviso.
Scritture protette. VueLityX accetta messaggi solo dalla pagina del dev server, con un confronto esatto dell'indirizzo, e scrive solo nelle cartelle del gioco. Anche usando l'editor nel browser fuori da VueLityX, il plugin di Vite accetta solo richieste dalla pagina del dev server e ha limiti di dimensione, così un altro sito aperto nel browser non può scrivere file nel progetto.

#Delphi #VueJS #CBuilder #LowCode #WebDevelopment #VueLityX #PlyxSQL

venerdì 30 ottobre 2026

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 30 OTT 2026

Free download https://vuelityx.com/

https://pgsoft.it/plyxhtml/

https://pgsoft.it

In attesa del prossimo rilascio di PythonLabs non puoi fare a meno dei tree tools free di PGSOFT

#Delphi #VueJS #CBuilder #LowCode #WebDevelopment #VueLityX #PlyxSQL

Delphi, C++Builder e RAD Studio sono marchi o marchi registrati di Embarcadero Technologies, Inc. VueLityX non è affiliato, sponsorizzato né approvato da Embarcadero. Tutti gli altri marchi appartengono ai rispettivi proprietari.

giovedì 29 ottobre 2026

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 29 OTT 2026

Free download https://vuelityx.com/

#Delphi #VueJS #CBuilder #LowCode #WebDevelopment #VueLityX

lunedì 26 ottobre 2026

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt prossimo al rilascio

Free VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 26 OTT 2026

Da quando ho iniziato VueLityX l'obiettivo è uno solo: fare per Vue.js quello che Delphi/CBuilder ha fatto per Windows. Un ambiente RAD vero, dove disegni l'interfaccia, colleghi i dati e gli eventi, provi e correggi, senza perdere mai il controllo del codice. Nelle ultime settimane sono arrivate alcune delle funzioni che più avvicinano VueLityX a quell'idea: ecco cosa c'è di nuovo.

In breve

Debugger sull'anteprima, con breakpoint, passo a passo e variabili
Breakpoint direttamente nell'editor, con un clic sul margine
Language server Vue (Volar) nell'editor: errori veri, completamento con i tipi, rinomina su tutto il progetto
Align e Anchors come in Delphi, per i componenti Vue
Object Repository: componenti e viste riutilizzabili tra progetti
Esplora database e dati a design time
Interfaccia in 9 lingue
FormCapacitorBuilder: dal progetto Vue all'app Android (APK e AAB) con Capacitor

1. Un debugger come quello di Delphi/CBuilder, sull'anteprima

Il menu Debug apre un debugger che lavora direttamente sull'anteprima dell'app, senza DevTools esterni. Si mettono i breakpoint sulle righe dei file .vue e .js del progetto e, quando il codice ci passa, l'esecuzione si ferma.

Comandi di Delphi/CBuilder: Continua (F9), Passo (F8), Entra (F7), Esci (Maiusc+F8).
Stack delle chiamate e variabili espandibili: locali, di chiusura, di blocco e del modulo, con i ref mostrati per il loro valore.
Valuta / Modifica: scrivi un'espressione (conta.value, conta.value = 5) e vedi subito il risultato.
Le righe sono quelle del tuo file: grazie alle source map di Vite, il breakpoint messo alla riga 31 di Home.vue si ferma proprio lì, non nel codice generato.
Anche il codice di avvio: "Ricarica pagina" riparte dall'inizio, così ci si ferma anche nello <script setup> e nel primo disegno del template.
Le librerie si saltano (node_modules, client di Vite) e si sceglie se fermarsi sulle eccezioni.

2. Breakpoint nell'editor, con un clic

Come in Delphi, il breakpoint si mette cliccando sul margine a sinistra dei numeri di riga, oppure con F5 sulla riga del cursore. Compare il pallino rosso; un altro clic lo toglie.

Funziona anche a debugger chiuso: quando lo apri, i breakpoint sono già lì.
Se aggiungi o togli righe sopra, il pallino segue il codice.
Quando il debugger si ferma, la riga in esecuzione è evidenziata in giallo nell'editor.
Aprendo il debugger, mostra già il file dell'editor alla riga del cursore.

3. L'editor ora "capisce" Vue: arriva il language server

L'editor di codice di VueLityX è basato su Monaco, lo stesso motore di Visual Studio Code. Adesso è collegato anche al language server ufficiale di Vue (Volar), quello che usa VS Code: l'editor non si limita più a colorare il testo, conosce davvero il progetto.

Errori TypeScript e Vue mentre scrivi, nella lingua dell'IDE: "Il tipo 'string' non è assegnabile al tipo 'number'".
Completamento con i tipi: scrivendo <Hello l'editor propone le props del componente figlio.
Import automatici: scegli computed dall'elenco e l'import da vue si aggiunge da solo.
Tipo al passaggio del mouse e firma dei parametri quando apri la parentesi di una funzione.
Vai alla definizione (F12 o Ctrl+clic), anche in un altro file, che si apre alla riga giusta; Alt+F12 per l'anteprima al volo.
Rinomina su tutto il progetto (F2): rinomini una funzione in App.vue e cambia anche in utils.ts.
Formatta documento, mantenendo gli a-capo del file.

Il language server gira in un piccolo processo Node.js che VueLityX avvia da solo in background (la prima volta installa i pacchetti necessari) e chiude insieme all'IDE. Un pallino "Vue" in basso a destra nell'editor ne mostra lo stato.

4. Align e Anchors, come in Delphi/CBuilder

Chi viene da Delphi/CBuilder conosce bene Align := alClient e Anchors := [akRight, akBottom]. Ora esistono anche per i componenti Vue, come direttive sul tag, e si impostano dall'Object Inspector:

<header v-align="'top'">...</header>
<aside  v-align="'left'">...</aside>
<main   v-align="'client'">...</main>      <!-- riempie lo spazio che resta -->
<button v-anchors="'right,bottom'">OK</button>

Dietro c'è CSS moderno (griglia e flex), applicato solo come stile in linea: nessun CSS globale, e togliendo la direttiva l'elemento torna com'era. Funziona con Vite e con Nuxt.

5. Object Repository

L'equivalente di File > New > Other... e Add to Repository di Delphi. Un componente o una vista riuscita si salva nel Repository e si riusa in qualunque progetto, con i suoi file e le dipendenze che richiede.

Elementi di serie già pronti: barra di stato, finestra di dialogo, pagina con layout, scheda di accesso.
Elementi personali, salvati nella propria cartella utente.
Nomi e descrizioni nelle lingue dell'IDE.

6. Esplora database e dati a design time

Esplora database (il Data Explorer di Delphi) si collega al database del backend con FireDAC e mostra tabelle, campi con tipo e chiave, e un'anteprima dei dati. Con un clic, "Crea datasource dalla tabella" aggiunge al DataModule un datasource REST già pronto verso l'API di quella tabella, anche con chiavi composte.

Con i dati a design time l'anteprima si vede piena anche mentre la disegni: dalla combo "Dati" scegli fra dati reali, dati di esempio o datasource spenti. Le griglie mostrano un badge che dice da dove arrivano i dati, così non si confonde mai l'esempio con il vero.

7. Sempre più Delphi/CBuilder: eventi, azioni, struttura

Scheda Eventi nell'Object Inspector: assegni un gestore scegliendo fra le funzioni dello <script setup> o creandone uno nuovo, e lo rinomini o lo scolleghi.
ActionList: le azioni del progetto (testo, suggerimento, scorciatoia, abilitazione) in un editor dedicato, e "Collega azione..." mette v-action sul componente.
Structure View: l'albero dei componenti, dove si spostano gli elementi trascinandoli e si rilasciano nuovi componenti dalla galleria.
Crea componente da qui: un pezzo di template diventa un componente nuovo, già importato.
Annulla / Ripeti di tutte le modifiche fatte dal designer, e il pannello Problemi che porta al file e alla riga dell'errore.

8. VueLityX parla 9 lingue

L'interfaccia è disponibile in italiano, inglese, tedesco, francese, spagnolo, portoghese, russo, cinese e giapponese, compresi i nuovi strumenti: debugger, repository, esplora database e i messaggi del language server. La lingua si cambia dal menu, senza riavviare.

9. Dalla web app all'app Android: FormCapacitorBuilder

Con Build Capacitor... un progetto Vue + Vite diventa un'app Android nativa grazie a Capacitor, pronta da installare sul telefono o da pubblicare sul Play Store. Lo stesso codice che gira nel browser, senza riscrivere nulla. La finestra si apre già sulla cartella del progetto attivo: si compilano pochi campi e si preme Build.

Cosa si imposta

Nome dell'app, nome breve, descrizione, versione e codice di versione.
ID dell'app (es. it.miaazienda.miaapp), proposto in automatico dal nome breve e controllato nel formato.
Icona: un PNG (consigliato 1024×1024) da cui si generano tutte le icone Android, con anteprima.
Orientamento: automatico, verticale o orizzontale.
URL del backend: l'indirizzo del server che l'app userà per le API.
Tipo di output: APK di debug, APK release o AAB per il Play Store, con keystore, alias e password per la firma.
Opzioni per lo sviluppo: traffico HTTP non cifrato (per i server di prova) e debug della WebView da Chrome.

La configurazione si salva nel progetto e si ritrova alla volta successiva. Le password invece non vengono mai salvate.

Cosa fa da solo, in 10 passi

Controlla l'ambiente: Java JDK 17 o superiore (anche quello incluso in Android Studio) e Android SDK, cercati nei posti abituali.
Installa Capacitor se manca (@capacitor/core, cli, android), allineando le versioni fra loro.
Genera capacitor.config.json. Se il progetto ha già un capacitor.config.ts o .js, lo rispetta e non lo tocca.
Aggiorna package.json (nome, versione, script cap:*) senza toccare gli script esistenti.
Adatta il codice web alla WebView: percorsi relativi in vite.config, Vue Router in modalità hash (così ricarica, link diretti e tasto Indietro funzionano sempre), e l'indirizzo delle API letto da VITE_API_BASE.
Build Vite con un .env.production che punta al backend remoto.
Aggiunge la piattaforma Android (solo la prima volta) e sincronizza Capacitor.
Genera le icone con @capacitor/assets.
Scrive nel progetto Android nome dell'app, ID, versione e orientamento.
Compila con Gradle e copia il risultato in dist-capacitor, con un nome chiaro come miaapp-1.0.0-release.aab.

Pensato per non fare danni

I file del progetto web modificati per la build vengono salvati prima e ripristinati alla chiusura: il progetto resta quello di sempre.
La build si può annullare in qualsiasi momento, e si fermano anche i processi figli (npm, Node, Gradle, Java). Durante la build la finestra non si chiude per sbaglio.
Se Gradle fallisce, il registro mostra le righe di errore e suggerisce la causa più probabile: licenze dell'SDK da accettare, JDK sbagliato, SDK non trovato. Il log completo finisce in capacitor-build.log.
Un pulsante apre il progetto in Android Studio (npx cap open android), per emulatore, debug nativo e plugin.

#Delphi #VueJS #CBuilder #LowCode #WebDevelopment #VueLityX

mercoledì 21 ottobre 2026

VueLityx© Il builder visuale per Vue.js, Vite e Nuxt

POSTED BY GIULIANO PAGNINI, 22 OTT 2026

Quante volte hai iniziato un nuovo progetto Vue e hai passato le prime ore… a configurare? Cartelle, dipendenze, import, componenti da collegare a mano.

E se potessi saltare tutto questo e passare subito alla parte che conta davvero: il tuo prodotto? Ti presento VueLityX, il builder visuale che Vue meritava. VueLityX è un ambiente RAD, Rapid Application Development, sviluppato da pgsoft.it per creare applicazioni Vue.js con Vite e Nuxt in modo rapido e professionale.

L’idea è semplice: meno configurazione, più prodotto. Costruisci le tue pagine in modo visuale, con il drag & drop. Scegli un componente, lo trascini dove ti serve e VueLityX fa il resto: inserisce il markup nel template, aggiunge l’import nello script setup e crea automaticamente i file del componente nel progetto. Ma non perdi mai il controllo del codice. Accanto alla parte visuale hai un editor integrato: tutto quello che VueLityX genera è codice Vue pulito, leggibile, che puoi modificare quando vuoi.

JavaScript o TypeScript? Scegli tu: il tool si adatta al tuo progetto. Ogni componente porta con sé le proprie dipendenze, e VueLityX le installa per te. Niente più pacchetti dimenticati o versioni da allineare a mano. Tutto è guidato da JSON: componenti, configurazioni, contenuti del sito. Una sola fonte di verità, facile da mantenere, versionare e riutilizzare tra un progetto e l’altro. E con l’integrazione dell’intelligenza artificiale, VueLityX ti aiuta a generare e rifinire componenti e pagine ancora più velocemente.Non è solo teoria. PackConfigurator, un configuratore 3D per l’ottimizzazione degli imballaggi, è stato sviluppato interamente con VueLityX, insieme al suo sito web in Nuxt.

Un’applicazione complessa, con grafica 3D e calcoli di ottimizzazione, costruita in una frazione del tempo abituale. VueLityX: per sviluppatori Vue che vogliono costruire di più, configurando di meno.

Scopri di più su vuelityx.com, iscriviti al canale e attiva la campanella per non perdere i prossimi tutorial.

https://vuelityx.com/

#Delphi #VueJS #CPPBuilder #LowCode #WebDevelopment #VueLityX

sabato 17 ottobre 2026

Free PlyxSQL© - 1.0.0.112

SQLManagerMenu: corretti bug nella gestione dei progetti e migliorata la robustezza del motore SQL

Introduzione

Lo sviluppo di SQLManagerMenu prosegue con un nuovo ciclo di manutenzione tecnica dedicato alla stabilità dell'applicazione, alla correttezza della gestione dei progetti e all'affidabilità dell'elaborazione degli script SQL.

L'obiettivo è rendere sempre più solida un'applicazione che integra gestione delle connessioni, navigazione degli oggetti database, generazione DDL, Query Builder ed editor SQL, con particolare attenzione alle differenze sintattiche tra i principali database relazionali.

Le ultime modifiche si sono concentrate sulla gestione dello stato del progetto, sulla tokenizzazione degli identificatori SQL e sul rafforzamento dei controlli durante l'elaborazione del DDL.

1. Corretta la gestione delle modifiche al progetto

Uno dei problemi individuati riguardava il comportamento del sistema durante il cambio della scheda attiva.

In precedenza, la semplice selezione di una scheda poteva determinare la marcatura del progetto come modificato, anche in assenza di modifiche effettive al contenuto.

Questo comportamento poteva generare richieste di salvataggio superflue e rendere meno chiara la distinzione tra navigazione nell'interfaccia e modifica dei dati.

La gestione è stata corretta per evitare che il solo cambio di scheda provochi automaticamente la marcatura del progetto come modificato.

È stato inoltre corretto l'handler responsabile della notifica delle modifiche, che in precedenza ignorava il parametro booleano ricevuto e impostava sempre lo stato di modifica.

Questi interventi costituiscono un passo importante verso una gestione più coerente dello stato del progetto.

2. Migliorata la tokenizzazione degli identificatori SQL

Un'altra area interessata dalle correzioni è il tokenizer utilizzato durante l'analisi degli script DDL.

I diversi database utilizzano convenzioni differenti per delimitare gli identificatori. Alcuni esempi sono:

Virgolette doppie per gli identificatori delimitati.
Backtick in MySQL e MariaDB.
Parentesi quadre in SQL Server.

All'interno degli identificatori possono inoltre comparire caratteri di escape che devono essere interpretati correttamente.

Il tokenizer è stato aggiornato per gestire meglio gli identificatori delimitati e le rispettive sequenze di escape, riducendo il rischio di suddivisioni errate dei token durante l'analisi del codice SQL.

Questa correzione è particolarmente importante quando si lavora con nomi di tabelle, colonne o altri oggetti che contengono caratteri speciali.

3. Migliorata la gestione degli input incompleti

La gestione degli script incompleti è un aspetto fondamentale per un parser DDL affidabile.

Un identificatore privo del delimitatore finale o una stringa non terminata possono indicare che il codice è stato troncato oppure che contiene un errore sintattico.

Il lavoro sul tokenizer ha introdotto controlli più rigorosi su queste situazioni, con l'obiettivo di evitare che input incompleti vengano interpretati come token validi.

La corretta gestione di questi casi contribuisce a rendere più prevedibili le fasi successive di parsing e generazione DDL.

4. Rafforzati i test del generatore DDL

La manutenzione ha interessato anche la suite di test del generatore DDL.

Sono stati aggiunti o ampliati test relativi a diversi casi limite, tra cui:

Identificatori contenenti caratteri di escape.
Stringhe e identificatori non terminati.
Regole di quoting specifiche di PostgreSQL.
Commenti annidati.
Rilevamento dei segnaposto negli script.

L'ampliamento dei test permette di documentare meglio il comportamento atteso dei componenti e costituisce una base più solida per le future modifiche.

La presenza di nuovi test, tuttavia, non equivale automaticamente alla certificazione del loro superamento: la suite deve essere eseguita e verificata nell'ambiente di compilazione previsto.

5. Migliorati i controlli sui segnaposto DDL

Gli script generati possono contenere segnaposto temporanei, come TODO, oppure sezioni incomplete che devono essere completate prima dell'esecuzione.

Il sistema dispone di controlli dedicati a questi casi, utilizzati anche nei percorsi di esecuzione degli script.

L'obiettivo è evitare che codice incompleto venga trattato come SQL pronto per essere eseguito.

Particolare attenzione è stata dedicata alla necessità di distinguere il testo effettivo del codice dai contenuti presenti nelle stringhe e nei commenti.

Questa area rimane oggetto di ulteriori verifiche per garantire una gestione coerente delle diverse convenzioni lessicali dei database supportati.

6. Attenzione alla compatibilità tra dialetti SQL

La gestione multi-dialetto rimane uno degli aspetti tecnici più importanti di SQLManagerMenu.

Un'istruzione valida su un database potrebbe non essere supportata da un altro, oppure potrebbe richiedere una versione minima specifica del server.

Per questo motivo, la generazione DDL deve tenere conto non soltanto del tipo di database, ma anche delle sue caratteristiche e della versione effettiva.

Tra gli aspetti che richiedono particolare attenzione rientrano:

La sintassi per creare o modificare procedure, funzioni e trigger.
Le regole di quoting degli identificatori.
I delimitatori utilizzati negli script composti.
Le differenze tra le versioni dei singoli DBMS.
Le proprietà dello schema che non possono essere rappresentate direttamente nel modello interno.

L'obiettivo è evitare che il generatore produca script apparentemente corretti ma incompatibili con il database di destinazione.

#SQL #database #ETL #DataEngineering #plyxSQL #FireDAC #PGSOFT

giovedì 8 ottobre 2026

Free PlyxSQL© - 1.0.0.111

PlyxSQL 111: il nuovo SQL Manager cross-database per sviluppatori professionisti

PlyxSQL v30 rappresenta una nuova importante evoluzione di un ambiente SQL progettato per lavorare con database differenti attraverso un'unica piattaforma.

La nuova versione introduce una revisione architetturale profonda che coinvolge gestione delle connessioni, SQL Builder, SQL Editor, Schema Designer, generazione DDL, capability SQL, versioni dei database e test di compatibilità.

L'obiettivo è ambizioso: offrire agli sviluppatori un ambiente nel quale la generazione SQL non dipenda semplicemente dal nome del database, ma dal contesto reale del server e dalle funzionalità effettivamente disponibili.

Un unico ambiente per database differenti

Uno dei problemi più complessi nello sviluppo di strumenti SQL multi-database è rappresentato dalle differenze tra i vari dialetti.

Una query valida su PostgreSQL potrebbe non essere valida su SQL Server.

Una sintassi disponibile su MySQL 8 potrebbe non essere disponibile su MySQL 5.7.

MariaDB e MySQL possono condividere molta sintassi, ma non sono sempre equivalenti.

DB2, Informix e Microsoft Access introducono inoltre numerose peculiarità specifiche.

PlyxSQL v30 affronta questo problema con una nuova architettura basata sul concetto di SQL Workspace.

SQL Workspace: il cuore della nuova architettura

Il nuovo TSQLWorkspaceContext raccoglie in un unico contesto tutte le informazioni necessarie alla gestione SQL.

Il Workspace comprende:

connessione;
dialetto SQL;
prodotto;
versione del server;
origine delle informazioni;
sessione SQL;
capability;
generazione del contesto.

Il vantaggio è importante: Builder, Editor, Designer e altre funzionalità possono lavorare sullo stesso contesto SQL.

L'architettura può essere rappresentata così:

Connessione
     │
     ▼
Tree Explorer
     │
     ▼
SQL Workspace Context
     │
 ┌───┼───────────────┐
 ▼   ▼               ▼
Builder Editor   Schema Designer
     │
     ▼
SQL / DDL

Questa struttura riduce drasticamente il rischio che componenti differenti utilizzino informazioni diverse sul database attivo.

Database, prodotto e versione: una distinzione fondamentale

PlyxSQLv30 introduce una gestione più precisa dell'identità del database.

Non viene considerato soltanto il semplice dialetto.

Il sistema distingue tra:

Dialect

Product

Server Version

Session

Capabilities

Questa distinzione è fondamentale per gestire correttamente database come MySQL e MariaDB.

MySQL e MariaDB finalmente distinti

MySQL e MariaDB condividono moltissima sintassi, ma non sono lo stesso prodotto.

La v30 introduce quindi una gestione esplicita del prodotto.

Questo permette al sistema di sapere che una connessione utilizza:

Dialect: MySQL
Product: MariaDB

quando questa è la rappresentazione sintattica più appropriata.

Il risultato è una base molto più solida per gestire le differenze specifiche dei due database.

AutoDetect più affidabile

La funzione di autodetection è stata migliorata per evitare che il rilevamento automatico sovrascriva arbitrariamente le impostazioni definite manualmente.

Il sistema può utilizzare informazioni provenienti da:

driver;
server;
progetto;
configurazione manuale.

La scelta manuale dell'utente viene quindi rispettata.

Questo rende il comportamento molto più prevedibile quando si lavora con configurazioni particolari o database legacy.

Capability Engine: sapere cosa può realmente fare il database

Una delle innovazioni architetturali più importanti della v30 è il nuovo sistema centralizzato delle SQL Capability.

Il progetto dispone ora di un Core che descrive le funzionalità supportate dai vari database.

Tra queste troviamo:

Foreign Key;
Check Constraint;
Views;
Triggers;
Routines;
Sequences;
Lateral;
Apply;
Returning;
Generated Columns;
JSON;
Pagination;
altre funzionalità specifiche.

Il Builder può quindi basare la generazione SQL sulle funzionalità disponibili invece di utilizzare esclusivamente controlli basati sul nome del database.

Perché le Capability sono così importanti?

Consideriamo un esempio.

Non è sufficiente sapere:

Database = SQL Server

Bisogna sapere anche:

SQL Server
+
versione
+
sessione
+
feature disponibili

Una funzionalità può infatti essere stata introdotta soltanto in una determinata versione.

Per questo PlyxSQL v30 considera la versione del server come parte integrante del contesto SQL.

Server Profile

Il SQL Builder utilizza un profilo server più completo attraverso il concetto di:

TSQLServerProfile

Il profilo combina:

dialetto;
prodotto;
versione;
capability;
sessione.

Questo permette al generatore SQL di prendere decisioni molto più precise.

Il risultato è un Builder più consapevole dell'ambiente nel quale sta operando.

SQL Builder più intelligente

Il Builder è stato profondamente migliorato nella gestione delle funzioni SQL.

In particolare sono stati introdotti contratti espliciti per le funzioni scalari.

Una funzione può essere:

nativa;
emulata;
non supportata;
dipendente dalla versione.

Questo è molto più sicuro rispetto a supporre che una funzione con lo stesso nome abbia necessariamente lo stesso comportamento su tutti i database.

Supporto specifico per DB2

DB2 presenta numerose particolarità sintattiche.

La v30 introduce un renderer specifico per le funzioni scalari DB2.

Questo consente di gestire in modo dedicato funzioni relative a:

stringhe;
lunghezza;
substring;
padding;
funzioni numeriche.

Il Builder non deve quindi trattare DB2 semplicemente come una variante generica dello standard SQL.

Supporto specifico per Informix

Anche Informix dispone di una gestione dedicata per le funzioni scalari.

Questa scelta consente di produrre SQL maggiormente aderente alle caratteristiche del database.

È un passaggio importante per un prodotto che vuole supportare realmente anche database meno diffusi rispetto ai classici MySQL, PostgreSQL e SQL Server.

Supporto specifico per Microsoft Access

Microsoft Access rappresenta un ambiente particolarmente diverso rispetto ai database server tradizionali.

La v30 introduce una gestione specifica delle sue funzioni SQL e delle sue peculiarità.

Questo permette di evitare di utilizzare automaticamente la sintassi dei database server-oriented.

Pagination cross-database

La gestione della paginazione SQL è stata resa più robusta.

Sono stati affrontati in particolare:

offset negativi;
overflow;
conversione dei valori;
differenze tra database;
sintassi specifiche dei vari dialetti.

La generazione della paginazione viene quindi effettuata tenendo conto delle caratteristiche del database.

Quoting degli identificatori

Il quoting è un'altra area particolarmente delicata in un ambiente SQL multi-database.

PlyxSQLv30 dispone di una gestione più strutturata del quoting.

Questo consente di tenere conto delle differenze tra:

SQL Server;
PostgreSQL;
MySQL;
MariaDB;
Firebird;
InterBase;
Access;
altri dialetti supportati.

Il quoting viene quindi trattato come una caratteristica del contesto SQL e non come una semplice operazione testuale.

DDL: una nuova architettura unificata

La gestione del DDL è stata completamente riorganizzata.

La v30 introduce una struttura composta da:

SQL DDL Service
DDL Generator
SQL DDL IR

L'utilizzo di un modello intermedio consente di separare la descrizione dell'oggetto dalla sintassi specifica del database.

Questo rende la generazione DDL più facilmente estendibile.

DDL coerente tra Tree e Designer

Una delle migliorie più importanti è la maggiore uniformità tra le operazioni effettuate dal Tree Explorer e quelle effettuate dallo Schema Designer.

La stessa architettura DDL viene utilizzata per le diverse modalità operative.

Questo riduce il rischio di avere:

SQL differente a seconda del punto dell'applicazione dal quale viene eseguita la stessa operazione.

Foreign Key, Index e Constraint

La gestione degli oggetti strutturali del database è stata migliorata.

Particolare attenzione è stata dedicata a:

Foreign Key;
Index;
Constraint;
Check Constraint;
quoting;
nomi degli oggetti;
riferimenti tra tabelle;
differenze DDL tra database.

La capability matrix permette inoltre di distinguere meglio ciò che un database può realmente eseguire.

Trigger più accurati

La gestione dei trigger è stata resa più precisa.

In particolare vengono considerate le differenze relative ai trigger:

INSTEAD OF

che non sono disponibili allo stesso modo in tutti i database.

Questo evita di trattare tutte le implementazioni dei trigger come equivalenti.

Routine e cataloghi database

La gestione delle routine è stata migliorata attraverso una classificazione più precisa degli oggetti restituiti dai cataloghi database.

Questo consente di distinguere meglio:

procedure;
funzioni;
routine;
differenti tipologie catalogate dai vari DBMS.

Il Tree Explorer può quindi rappresentare gli oggetti in modo più coerente.

SQLite e le sue particolarità DDL

SQLite non dispone dello stesso modello DDL dei database server tradizionali.

La v30 gestisce esplicitamente le limitazioni relative alle constraint e alle operazioni DDL.

In particolare vengono evitate operazioni che SQLite non può eseguire direttamente con la stessa modalità di altri database.

SQL Script Runner

La gestione degli script SQL è stata centralizzata attraverso il nuovo:

SQLScriptRunner

Il sistema gestisce:

analisi;
suddivisione;
pianificazione;
esecuzione;
gestione degli errori.

Questo permette di avere una pipeline SQL più coerente.

SQL Script Splitter

La suddivisione degli script è stata migliorata per gestire correttamente le singole istruzioni.

Questo è particolarmente importante quando uno script contiene strutture SQL più complesse.

La separazione tra parsing dello script e sua esecuzione permette inoltre di migliorare progressivamente il motore senza dover modificare tutte le funzionalità che utilizzano SQL.

Esecuzione DDL asincrona

Le operazioni DDL possono essere eseguite attraverso un modello asincrono.

Questo è fondamentale per database:

remoti;
lenti;
con molti oggetti;
soggetti a lock;
con operazioni DDL lunghe.

L'interfaccia può quindi rimanere reattiva durante le operazioni più pesanti.

SQL Execution Matrix

Una delle funzionalità più interessanti della v30 è la:

SQL Execution Matrix

Non ci si limita a verificare che il Builder produca una stringa.

Le query possono essere eseguite realmente sul database.

La matrice verifica attualmente diverse categorie, tra cui:

funzioni scalari;
quoting;
pagination;
coerenza del dialetto.

Questo introduce un concetto molto importante:

testare SQL realmente eseguibile e non soltanto SQL apparentemente corretto.

Dal test statico al test reale

Un SQL Builder può produrre una query apparentemente perfetta:

SELECT ...

ma soltanto il database può confermare se quella query è realmente valida.

La SQL Execution Matrix introduce quindi una verifica concreta del comportamento del generatore.

È un passo fondamentale verso un ambiente SQL professionale.

Sincronizzazione Tree Explorer, Builder ed Editor

La v30 migliora il collegamento tra i tre componenti principali:

Tree Explorer

Gestisce le connessioni e il Workspace.

SQL Builder

Genera SQL sulla base del Workspace.

SQL Editor

Visualizza e modifica il codice SQL.

Il flusso diventa quindi:

CONNESSIONE
     ↓
TREE EXPLORER
     ↓
WORKSPACE
     ↓
BUILDER
     ↓
SQL
     ↓
EDITOR

Questo rende l'interazione tra i componenti molto più prevedibile.

SQLManagerMenu come orchestratore

SQLManagerMenu rimane il centro operativo dal quale vengono avviate numerose funzioni.

La nuova architettura, però, riduce progressivamente la quantità di logica duplicata all'interno del menu.

Il menu coordina le operazioni mentre il Workspace e i servizi specializzati gestiscono le informazioni SQL.

Questa separazione rende il progetto più facilmente manutenibile.

Cache e invalidazione del contesto

La gestione della cache è stata integrata con il concetto di generazione del Workspace.

Quando cambia il contesto della connessione, le informazioni precedenti possono essere invalidate.

Questo è particolarmente importante quando l'utente passa rapidamente tra database differenti.

Ad esempio:

PostgreSQL
   ↓
SQL Server
   ↓
Firebird
   ↓
MariaDB

senza riavviare l'applicazione.

Gestione delle versioni server

La versione del server è diventata una componente importante del modello SQL.

Questo consente di gestire meglio le differenze tra:

MySQL 5.7
MySQL 8.x

oppure:

SQL Server legacy
SQL Server moderno

e analogamente per gli altri DBMS.

Questa impostazione è fondamentale per evitare che il Builder consideri automaticamente tutte le versioni di un database equivalenti.

Una vera architettura Cross-Dialect

La v30 non si limita quindi a tradurre:

SQL standard → SQL database

L'approccio è più evoluto:

Workspace
    ↓
Dialect
    ↓
Product
    ↓
Version
    ↓
Session
    ↓
Capabilities
    ↓
Renderer
    ↓
SQL

Questo rappresenta un modello molto più vicino a un vero SQL compiler/generator cross-database.

Perché la v30 è importante

La vera innovazione della versione 30 non è una singola funzione.

È il modo in cui le diverse funzionalità sono state collegate.

La piattaforma dispone ora di una catena architetturale molto più coerente:

Connection → Workspace → Capability → Renderer → SQL → Execution

Questo permette di costruire in futuro funzionalità ancora più sofisticate senza dover duplicare continuamente la logica per ogni database.

I database supportati

L'architettura v30 è progettata per lavorare con numerosi DBMS, tra cui:

Firebird;
InterBase;
PostgreSQL;
MySQL;
MariaDB;
Microsoft SQL Server;
Oracle;
SQLite;
IBM Db2;
Informix;
Microsoft Access.

Il valore dell'architettura sta proprio nella capacità di gestire le differenze tra questi ambienti mantenendo un modello comune.

PlyxSQL v30 rappresenta una delle evoluzioni architetturali più importanti del progetto.

Il passaggio fondamentale è quello da una gestione SQL basata principalmente sul semplice dialetto a una gestione basata sul contesto completo:

Database + Product + Version + Session + Capability + Renderer

Questo approccio permette di affrontare in modo molto più professionale la complessità del mondo SQL.

Il Builder non deve più semplicemente chiedersi:

"Quale database sto utilizzando?"

ma deve poter rispondere a una domanda molto più precisa:

"Quale sintassi SQL è realmente disponibile in questo specifico ambiente?"

È questa filosofia che rende la v30 una piattaforma particolarmente interessante per lo sviluppo di applicazioni database multi-DBMS.