devcode-it
Strutturazione actions.php esterni per sviluppare più moduli esterni
Nello sviluppo di moduli e plugins esterni, molte volte c'è la necessità di modificare i file actions.php per aggiungere azioni, come ad esempio svolgere altre query dopo l'aggiunta di un articolo in fattura, o in intervento, senza per forza modificare il file actions.php degli interventi. Finora la soluzione era creare un file actions.php nella cartella custom/, ma questo limita la possibilità di mantenere aggiornato OSM.
L'idea era di creare un actions.php aggiuntivo da includere dopo ogni actions.php di un modulo, creando una cartellina di "override" dentro ogni modulo. Faccio un esempio:
Nuovo modulo: MODULO_X
Funzionalità: esegue delle query in più dopo l'aggiunta di un articolo in fattura, ed invia una mail in background.
Struttura cartelle modulo: modules/modulo_x/override/fatture/actions.php
Quando verrà fatto un submit del form principale delle fatture, dopo aver eseguito il case 'addarticolo', si uscirà dallo switch. Dopo lo switch standard delle fatture, la struttura di OSM dovrebbe cercare sulle cartelle di ogni modulo, dentro override/nome_modulo_attuale/ se c'è un actions.php ed includerlo, così in quel file aggiuntivo verrebbe aggiunto un altro switch, sempre con lo stesso case 'addarticolo', dove si eseguono operazioni aggiuntive.
Può essere una soluzione? Controindicazioni / idee alternative?
In alternativa nel file custom/actions.php basterebbe effettuare un inclusione del file actions.php di default, così da avere nel file personalizzato le sole operazioni aggiuntive.
Lo scopo sarebbe di poter creare moduli aggiuntivi, che eseguano azioni negli actions.php dei moduli standard senza modificare questi ultimi e senza crearne una copia modificata in custom/.
Quindi:
- cartella custom per personalizzare funzioni standard del gestionale
- cartella override per nuove funzionalità NON standard
corretto?
Cartella custom/ per personalizzare i moduli standard, mentre override/ la introdurrei nei moduli aggiuntivi per aggiungere istruzioni extra negli actions.php, però di altri moduli. In particolare, l'override servirebbe per estendere le funzioni degli actions.php di moduli già installati, senza toccare le cartelle di questi ultimi, per mantenere più facilmente aggiornabile osm pur creando moduli aggiuntivi indipendenti, che aggiungono funzioni. Forse è sbagliato il termine "override", perché indica una sovrascrittura. È più un'estensione di funzionalità, o un'aggiunta...
Bella idea! Da aggiungere sicuramente, si può usare il termine "extensions" mi sembra piú consono allo scopo!
Ragionando sulla logica dei moduli personalizzati e modificati, potrebbe essere più utile evitare la gestione tramite una logica del genere che complica la gestione di aggiornamenti e controllo delle modifiche. A livello pratico, quando è necessario modificare un comportamento del gestionale, si possono verificare tre situazioni:
- Modifica di una parte ridotta di un componente esistente
- Modifica estensiva di un componente esistente
- Creazione di e integrazione con un nuovo componente
Primo e secondo caso
Il primo caso, la modifica di una parte ridotta di un componente esistente, risulta solitamente la più comune: alcuni utenti necessitano dei campi aggiuntivi, oppure desiderano una grafica leggermente diversa, oppure ancora non vogliono vedere campi che ritengono di ridotto interesse personale. Il problema in questo caso consiste nel fatto che le modifiche, essendo ridotte, vengono effettuate solo in alcuni file del modulo. In caso di aggiornamento si può quindi verificare che il modulo di base viene modificato anche in modo estensivo, ma i file modificati vengono mantenuti e devono essere aggiornati (cosa che spesso sfugge).
Il secondo caso, la modifica estensiva di un componente esistente, è caratterizzata da un copia-incolla iniziale di tutto il modulo originale su cui si procede ad effettuare le modifiche. In caso di aggiornamento, il modulo modificato dovrebbe continuare a funzionare senza problemi con la relativa logica personalizzata. In ogni caso, è consigliata la revisione delle modifiche per sistemare eventuali problemi, quindi si può argomentare che questa situazione non pone particolari problemi.
Terzo caso
Il terzo caso risulta il più complesso, e al momento il caso gestito in modo peggiore. Se la nuova componente è indipendente dal resto del gestionale, non si verificano problemi particolari. Se invece il modulo deve influenzare il comportamento del gestionale, la faccenda diventa più complessa.
Esempio pratico: il modulo Distinta base deve influenzare il modulo Articoli, in modo tale da integrare alcune funzioni di utility nella classe Articoli. L'unico modo per effettuare questa modifica è, al momento, sovrascrivere la classe Articoli in modo completo (ricadendo nel primo caso).
Possono però essere necessari altri comportamenti più complessi, basati su determinati eventi. In questo caso si può pensare alla gestione attuale dell'invio email ai tecnici per le modifiche delle sessioni di lavoro su un intervento. L'unico modo per gestire la situazione è stato includere una modifica nel modulo Interventi per gestire manualmente l'invio email. Potrebbe quindi essere molto utile considerare un sistema di eventi che le varie componenti del gestionale possono ascoltare e seguire.
Ci sono certamente altri casi che al momento non mi vengono in mente. @loviuz @lucasalva87 Potreste descrivere altre caratteristiche delle personalizzazioni in questo caso?
Problema organizzativo
Una ulteriore problematica risulta al momento la difficoltà intrinseca di individuare le modifiche dei moduli, poiché è necessario controllare manualmente all'interno di ogni componente se esiste una cartella custom/ non vuota. Come soluzione a questo problema propongo di spostare tutte le modifiche al software di base in una cartella custom/ (o nome simile) nella cartella principale, in modo da rendere tutte le personalizzazione più accessibili.