Revisione dei Componenti #793
Description
Comportamento richiesto
Al fine di rendere indipendenti i componenti del gestionale da una struttura fisica predefinita, propongo una revisione della struttura di modulo/plugin/stampe/widget basata sulle classi e interfacce che è già in implementazione nella branch future.
A livello più generale, OpenSTAManager funziona principalmente tramite moduli. I moduli possono avere pagine personalizzate, link a file non-standard e comportamenti variabili.
Per garantire questa libertà anche negli altri componenti, si prevedere l'introduzione di due interfacce.
Interfaccia Components\BootableInterface:
- getManager()
Interfaccia Components\ComponentInterface:
- boot(SlimApp $app): inizializza il componente
- render(array $args = []): genera la pagina HTML relativa al componente, che viene utilizzata in contesti limitati
- updates(): restituisce un array con gli aggiornamento del componente
Classe astratta Components\Component (implementa Components\ComponentInterface):
- autoload(): Gestisce l'inclusione delle componenti PHP necessarie al componente.
- views(): Gestisce la registrazione dei template Twig del componente.
- routes(SlimApp $app): Gestisce la registrazione dei percorsi navigabili per il componente.
Queste strutture permettono la gestione di tutti i comportamenti delle componenti attuali del gestionale, in particolare prevedendo che tutti i modelli Eloquent di tipo Module, Plugin, PrintTemplate, Widget implementino l'interfaccia Components\BootableInterface e prevedano una classe standard di tipo Components\ComponentInterface come manager.
In questo modo il gestionale può includere tutti i componenti attraverso una ricerca nel database e il richiamo del metodo boot() del manager relativo.
Come si può notare, questo comportamento è simile al precedente sistema di inclusione dei file modutil.php, con il vantaggio che in questo caso viene esteso ad altri componenti oltre ai moduli.
Al tempo stesso però per ogni componente del gestionale è necessario richiamare una classe, e pertanto si può verificare una riduzione delle prestazioni di avvio di OpenSTAManager (da verificare). Se ciò dovesse verificarsi, si può considerare un sistema di requisiti può completo introducendo la necessità che solo i moduli necessari per una definita pagina vengono caricati, con le relative dipendenze (da approfondire).
Il problema può evidente risulta in ogni caso la retro-compatibilità, che diviene difficile da mantenere. E' stato implementato un sistema basilare, per esempio per i moduli in Modules/Retro, che però risulta limitato ai casi di default del sistema attuale: ovvero, queste classi di retro-compatibilità possono gestire i moduli che prevedono creazione-aggiornamento-rimozione dei record senza azioni aggiuntive. Moduli come Fatture, DDT, ... richiedono quindi una revisione considerevole a causa delle numerose richieste che effettuano ad altri file (in particolare per aggiunta/rimozione righe).