openstamanager icon indicating copy to clipboard operation
openstamanager copied to clipboard

Gestione modulare attraverso Composer

Open Dasc3er opened this issue 8 years ago • 0 comments

Per migliorare la scalabilità e il grado di manutenibilità del codice, in futuro potrebbe risultare utile gestire i moduli del progetto attraverso pacchetti indipendenti installati attraverso Composer. Un esempio di questa pratica può essere individuato nella maggior parte dei progetti moderni, dove diverse componenti dedicate a specifiche azioni vengono gestite in repository separate con un relativo controllo di versione.

Questa modifica permetterebbe alcuni importanti miglioramenti a livello di codice, tra cui il completo spostamento della gestione delle operazioni all'interno di classi generalizzate e non dipendenti da singoli file PHP, aumentando così la portabilità del progetto.

In particolare, proporrei una suddivisione del genere:

  • File di base del progetto (devcode-it/openstamanager) All'interno della repository principale potrebbe essere gestita la struttura del gestionale presente nella root del server; in particolare, la cartella per i log, per gli upload e per i temi, oltre che i file PHP necessari a completare le richieste HTTP. Di conseguenza, questa repository sarebbe dedicata a definire la struttura generale del gestionale per tutti i componenti che potrebbero essere personalizzati/inseriti/modificati dagli utenti.

  • Core del progetto La repository in questione conterrebbe tutte le strutture di base che si occuperebbero di far funzionare il progetto, preferibilmente gestite attraverso una logica ad oggetti. I file PHP della repository principale richiamerebbero semplicemente queste classi per rispondere alla richieste HTTP, senza effettuare alcun tipo di operazione indipendente.

  • Repository dei moduli Ogni modulo possiederebbe una repository apposita, dedicata a gestire i contenuti da visualizzare nelle pagine (gli attuali file edit.php, actions.php, ... in futuro esportabili a loro volta in una struttura ad oggetti) e i file di installazione e aggiornamento. Il core del progetto dovrebbe occuparsi del relativo richiamo a questi moduli, dopo averli registrati a livello di database (come avviene attualmente).

Il vantaggio principale di questa struttura sarebbe l'indipendenza dei moduli, che potrebbero eventualmente essere aggiornati in modo separato rispetto al core secondo dei criteri stabilibili attraverso Composer. Inoltre, separando i contenti specifici dell'installazione (log, upload, temi) dall'effettivo codice dedicato alla loro gestione, sarebbe possibile procedere all'aggiornamento del core del progetto senza rischio di perdere o sovrascrivere dati personalizzati.

Ovviamente, questa modifica risulta piuttosto corposa: la propongo per poter introdurre un'ulteriore discussione sui possibili miglioramenti futuri.

Dasc3er avatar Oct 19 '17 16:10 Dasc3er