No, ho ho fatto il “mio” framework, come ci si aspetta da ogni programmatore. Non l’ho fatto perchè non servirebbe: meglio imparare ad utilizzare un buon framework, che reinventare la ruota. Ma è importante sapere i fondamentali. E’ importante essere in grado di scrivere un framework anche se non c’è l’esigenza di farne uno.
Questo è quanto è successo: dopo tanti anni di lavoro con Zend Framework, il progetto è stato abbandonato dal team che lo aveva sviluppato e portato avanti per anni. Sono cose che possono accadere nel mondo dell’open source e non solo. Ma io avevo speso molto tempo per realizzare applicazioni web basate su questo framework.
Zend Framework quindi è diventato Laminas Project ed è passato alla gestione di un altro team di sviluppo; esistono documenti e procedure che spiegano molto bene come trasferire su Laminas i vecchi progetti basati su Zend Framework, ma non ho apprezzato questo cambio di team e direzione del progetto; è importante utilizzare framework per tanti buoni motivi, ma è altrettanto importante poter fare affidamento su uno strumento e sul team che lo sviluppa.
Consideriamo anche che io ho iniziato a sviluppare con Zend Framework alla sua prima versione: Zend Framework 1. L’ho imparato con un paio di grandi libri e l’ho utilizzato per alcuni di progetti; l’ho imparato bene perchè in quel periodo, il mio lavoro principalre era stato proprio quello di ottimizzare l’implementazione di Zend Framework 1 per conto di un’azienda. Mi era piaciuto moltissimo: dopo anni di J2EE, Hibernate e altri mostri a tre teste con nomi simili. Poi era arrivato Zend Framework 2 e aveva rivoltato il tavolo portando tiepidi vantaggi. Ma c’erano cambiamenti interessanti che portavano un valore aggiunto alle applicazioni e l’ho apprezzato. Dopo anni e progetti con Zend Framework 2, è arrivato anche Zend Framework 3, che si è posto come un rinnovo totale di molti meccanismi che avevano reso grande Zend Framework 2: un nuovo mescolamento di carte che però non offriva grandi vantaggi.
Nel 2020 poi Zend Framework è stato proprio chiuso… ed è entrato in un altro progetto: Laminas Project. A questo punto il rapporto con Zend Framework si è un pò raffreddato.
Non potevo più continuare a rifare le cose da capo e avevo ormai molti progetti scritti per Zend Framework 3, chiedere ai clienti del budget per rifare di nuovo tutto da capo, poteva iniziare ad essere un problema.
Analizzando i progetti che avevo sviluppato con Zend Framework, ho realizzato che anche se conoscevo in maniera abbastanza approfondita buona parte degli strumenti forniti dal framework, alla fine usavo principalmente questi aspetti:
Non utilizzavo le millemila possibilità e componenti che il framework offriva. Un pò come con i nostri armadi: abbiamo tanti vestiti, ma nelle occasioni importanti finiamo per mettere sempre quella giacca che ci fa sentire comodi e tranquilli. Non è così?
La maggior parte delle interfacce venivano aggiornate da Javascript/jQuery che chiamava uno o più WebService che aggiornavano il database e restituivano i dati in formato JSON; la business logic si svolgeva nel Controller, nel metodo Action in particolare, e nelle classi su misura che avevo sviluppato nella cartella /vendor.
Non ho mai utilizzato il sistema di interazione con il database offerto da Zend Framework, perchè ho iniziato a programmare in PHP nel 2006 e sono abituato a scrivere manualmente le query: in questo modo posso ottimizzarle il più possibile nella fase di recupero dati. Mentre ho sempre utilizzato una classe DbMng scritta da me molti anni fa per le funzioni di inserimento e aggiornamento dati: la classe genera il codice per PDO, imposta i dati nel formato corretto e la lancia sul database. In 15 anni di utilizzo questa classe non ha mai dato problemi e anzi, è stata aggiornata, ottimizzata, migliorata ed è sempre stata compatibile con le versioni precedenti. Inoltre, fin dall’inizio sono stato abituato a progettare da zero i database seguendo le best practise di progettazione in MySql, quindi non ho mai avuto bisogno di utilizzare Doctrine o altre librerie simili in Zend Framework.
Quindi, ho deciso di tenere la struttura delle cartelle di Zend Framework (così da non dover riscrivere i progetti che avevo già fatto ed erano in produzione da anni) e ho riscritto la parte per gestire la navigazione delle pagine. In più, ho realizzato un sistema per generare codice PHP che funziona in Zend Framework (e quindi anche nella struttura/framework che ho realizzato).
Devo offrire continuità ai miei clienti e non posso correre ad aggiornare il framework ad ogni vulnerabilità in settori del framework che nemmeno utilizzo. Grazie quindi allo studio e all’esperienza sui progetti realizzati negli anni con Zend Framework 1,2,3 è nato questo piccolo framework che permette alle mie applicazioni di continuare a girare nella logica di Zend Framework, ma senza Zend Framework.
Il framework si integra nella struttura di Zend Framework ed composto principalmente dal file index.php che riceve tutte le richieste di navigazione fra pagine e verso i webservice che rispondono in formato JSON. Il file -application-config.php contiene le configurazioni che di solito non vanno modificate. Il file -change-here.php invece contiene le variabili che vanno sempre modificate quando si utilizza il framework per creare un nuovo progetto, semplificando anche la portabilità di queste applicazioni web che non hanno più biosgno del composer update dopo un trasferimento.
Non possiamo propriamente chiamarlo framework perchè un framework offre molto più di questo, ma questo è esattamente ciò che serviva a me per continuare a far funzionare i progetti sviluppati su Zend Framework. E anche i prossimi.
E’ importante restare sempre aggiornati sulle novità, in particolare sui più recenti design pattern che aprono la mente e permettono di crescere (ad esempio, ho imparato a lavorare con Flutter) ma devo anche soddisfare l’implicita richiesta di stabilità che viene dai miei clienti: lavorare con applicazioni web che funzionano e continuano a funzionare nel tempo.
In questo rifacimento, ho aggiunto qualche piccola feature in più, un paio di upgrade che ritengo utili dopo tanti anni passati a sviluppare applicazioni web. Quindi oltre a offrire le funzioni descritte sopra, il framework è costituito da due parti. Vediamole entrambe.
Creo i nuovi progetti a partire da questo, modifico il file -change-here.php e sviluppo le funzioni su misura.
Contiene strumenti che tornano utili quando viene utilizzato wtab per creare un nuovo progetto.
E’ il modulo per leggere in tempo reale i file di log creati nell’applicazione, un sistema per visualizzare gli error_log senza andarli a cercare nelle cartelle.
Il modulo accetta in ingresso un file CSV e lo carica nel sistema; una volta caricato, il popup Uploaded files permette di selezionare le colonne da utilizzare. Il sistema permette quindi di creare una tabella centrale e una serie di tabelle collegate con chiavi esterne, e di importare i dati presenti nel CSV.
Selezionando una tabella centrale nel database, viene creato in automatico un codice HTML, JS e PHP per visualizzare, modificare, cancellare e inserire righe. Molto utile per avere una base di codice per realizzare interfacce di lettura/modifica/inserimento/cancellazione (CRUD)
La cifratura dei dati è ridotta ad una semplice impostazione, mentre tutta la complessità è demandata alle classi del framework.
Il progetto prevede sempre la presenza di un’autenticazione di tipo Apache, altrimenti non parte; teoricamente, il controllo può essere disabilitato, ma se viene realizzato un progetto su questo framework, deve necessariamente essere configurata e utilizzata l’autenticazione Apache per aumentare il livello di sicurezza del progetto.
