coreBOS story: Perspectives

Siamo giunti alla settima parte della serie di post dedicati alla storia e allo sviluppo del progetto coreBOS. L’originale in inglese di questo articolo, scritto da Joe Bordes, si trova sul blog ufficiale di coreBOS.

perspectives

Concept

Una Perspective è un set di cambiamenti sul codice e sul database che converte uno stock di sistema di coreBOS in una verticalizzazione preparata per un segmento di mercato definito chiaramente.

Il concetto delle “prospettive” si appoggia su due features di coreBOS: coreBOS Updater e la struttura del codice e il sistema di packaging. Dal momento in cui abbiamo steso il codice in modo da non aver bisogno di pacchetti .zip e che tutto il codice è semplicemente lì, pronto ad essere modificato, possiamo facilmente definire una Perspective come:

  • un file composer.json per l’installazione di nuovi moduli
  • un file .xml di changeset di coreBOS Updater e i worker scripts ad esso associati
  • un patch per cambiare il codice (questo non dovrebbe essere richiesto)

Il patch aggiunge i cambiamenti del codice necessari alla verticalizzazione, mentre il changeset .xml di coreBOS Updater e i file composer.json definiscono il set di cambiamenti del database e i nuovi moduli necessari a convertire l’applicazione di base nella verticalizzazione del segmento di mercato che si desidera.

Come funziona

Le parti fondamentali di una Perspective sono il file composer .json e il ComposerInstall project che dev’essere installato con essa.

L’utilizzo del composer con un file composer.json appositamente creato permette di installare tutti i moduli necessari. Sono necessarie altre due cose per convertire uno stock coreBOS in una verticalizzazione:

  • un altro cambiamento sul database per unire i moduli. Ogni modulo avrà installato quello che può nel suo postinstall, ma ci saranno dei passaggi che sarà necessario fare una volta che i moduli saranno installati
  • patch i file di base. Idealmente questo passaggio non sarebbe necessario, ma in alcuni casi lo è ancora.

Per applicare il set finale di cambiamenti di coreBOS Updater, abbiamo creato la cbPerspective extension. Questo permetterà di creare alcuni changeset di coreBOS Updater e di raggrupparli in un passaggio finale di installazione che può essere facilmente integrato nel file di definizione del composer. Quindi l’obiettivo di cbPerspective non è quello di essere utilizzato così com’è nel suo repository, ma di essere personalizzato per ogni verticalizzazione. In altre parole, si avrà un’estensione TelemarketingPerspective nel suo repository che sarà una copia adattata di cbPerspective con un set di coreBOS Updater changeset da applicare dopo aver installato tutti i nuovi moduli per convertire uno stock coreBOS in un’applicazione da sogno per i telemarketers.

Con l’estensione creata e il composer sarà possibile installare tutti i nuovi moduli e fare tutti i cambiamenti post-database con questo comando:

composer.png

Per esempio, questo è un file perspective composer .json:

{

“repositories”: [

{

“type”: “vcs”,

“url”: “https://github.com/tsolucio/ComposerInstall”

},

{

“type”: “vcs”,

“url”: “https://github.com/tsolucio/adocDetail”

},

{

“type”: “vcs”,

“url”: “https://github.com/tsolucio/adocMaster”

},

{

“type”: “vcs”,

“url”: “https://github.com/tsolucio/coreBOSPackingSlip”

},

{

“type”: “vcs”,

“url”: “https://github.com/tsolucio/coreBOSEmployee”

},

{

“packagist”: false

}

],

“require”: {

“tsolucio/ComposerInstall”: “dev-master”,

“tsolucio/coreBOSPackingSlip”: “dev-master”,

“tsolucio/adocDetail”: “dev-master”,

“tsolucio/adocMaster”: “dev-master”,

“tsolucio/coreBOSEmployee”: “dev-master”

},

“scripts”: {

“post-install-cmd”: [

“tsolucio\\ComposerInstall\\ComposerInstall::postPackageInstall”,

“php modules/cbupdater/loadapplychanges.php modules/ConfigEditor/composer.xml”

],

“post-update-cmd”: “tsolucio\\ComposerInstall\\ComposerInstall::postPackageUpdate”

}

}

Se si alimenta con questo file composer.json un composer dall’inizio di un’installazione coreBOS si ottiene l’installazione in un solo passaggio dei moduli coreBOSPackingSlip, adocDetail, adocMaster and coreBOSEmployee. Se uno dei moduli fosse un’estensione cbPerspective, verrebbe installato con gli altri e lancerebbe i suoi changeset di coreBOS Updater. Quindi tutto ciò che resta da fare è applicare una patch specifica al codice di base per ottenere la verticalizzazione.

Note conclusive

Il modo in cui le perspectives sono state create in modo da essere un vantaggio per sviluppatori ed implementatori.

Immaginando di dover iniziare un progetto: normalmente si andrebbe a creare una nuova repository per il progetto, incorporarla nell’ultima versione di coreBOS ed iniziare ad installare moduli, applicare le modifiche e modificare il codice.

Con perspectives questo setup iniziale cambia un po’, e diventa così:

  • creare una nuova repository per il codice
  • incorporarvi l’ultima versione di coreBOS
  • installare coreBOS per avere un database valido per il progetto
  • trovare una perspective per il segmento di mercato del progetto e copiare il suo file composer.json all’inizio del progetto
  • lanciare l’installazione di composer per far sì che tutti i cambiamenti e i moduli vengano applicati
  • iniziare la personalizzazione sui bisogni specifici del clienti.

Come si può notare, l’unica differenza è che la perspective dà un set standard di moduli e impostazioni per uno specifico segmento di mercato, rendendo il setup iniziale più facile ed efficiente e allo stesso tempo permettendo di trarre benefici dall’esperienza di altri su questo tipo di configurazione.

Ogni perspective ha la sua repository in cui è possibile trovare il file composer.json principale, alcune informazioni sulle sue funzioni e i cambiamenti aggiuntivi che potrebbero essere necessari perché la perspective venga applicata completamente. Normalmente ogni perspective ha un’estensione cbPerspective, rinominata nella sua repository per combaciare con la perspective (cbPerspective è solo il template dell’estensione).

Mantenere un numero notevole di moduli separati richiede molto lavoro, soprattutto perché di solito si trova e sistema un errore in un modulo o si aggiunge una feature che tutti dovrebbero avere direttamente sulla repository privata del cliente, ma ne vale la pena.

Mi sono imbattuto in un concetto molto simile quando ho creato questo blog. Quando ho deciso di usare GRAV, mi sono accorto che loro usano il concetto di SKELETON PACKAGES per implementare la stessa funzionalità. È possibile approfondire questa feature e questo CMS (che raccomando caldamente) cliccando qui .

Grazie per la lettura!

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s