JuniorCMS è utilizzato con pieno successo in moltissimi siti e progetti web di alto livello per strutture che fondano il loro business sulle vendite on-line e sul webmarketing.

Abbiamo realizzato gestionali operativi su scala nazionale (Gruppo Volkswagen) e abbiamo realizzato micro-gestionali per la bottega sotto casa.

Stiamo realizzando il progetto AdessoWEB che consente di avvicinarsi al business on-line con un prodotto professionale ma estremamente semplice ed intuitivo.

Ora vogliamo andare avanti.

Ciò che in questi anni non abbiamo realizzato è una community di sviluppatori che utilizzano questo prodotto.

FroggleCMS nasce per risolvere questo enorme problema e creare una soluzione di gestione contenuti basata sul concetto di sviluppo veloce (RAD).

Powerfull Plugins

Alla base del progetto abbiamo messo il concetto di “plugin” inteso come “raggruppamento logico di software e risorse atto a risolvere una precisa necessità“.

Le necessità che un plugin può risolvere sono anch’esse tipizzate in:

1. libreria: condivisione di librerie e framework
2. servizio: definizione di servizi condivisi all’applicativo
3. applicativo: definizione di software gestionale utile
4. estensione: intervento di modifica e/o estensione di altri plugins
5. custom: insieme di applicativo ed estensione ove inserire il codice personalizzato sul singolo progetto.

Il plugin di estensione o custom permettono di modificare in modo approfondito sul comportamento dei livelli ingeriori per implementare soluzioni specifiche senza creare fork del progetto.

Life Cycle Guarantee

Anni di esperienza nella progettazione di applicativi ci hanno insegnato l’importanza del ciclo di vita del software.

Molte piccole web agency (l’Italia ne è piena) si trovano a sviluppare progetti in velocità per sopravvivere sul mercato.

La creazione di soluzioni realmente riutilizzabili è molto difficile in quanto, di progetto in progetto, nascono nuove necessità, ottimizzazioni, verticalizzazioni.

Di fatto ci si trova quasi sempre a creare piccoli fork di progetti preesistenti con il triste risultato di produrre decine di sub-versioni incompatibili di un progetto inizialmente coerente.

Il nostro devTeam è stato a lungo vittima di questo processo!

La soluzione proposta da FroggleCMS consente di isolare qualunque software in plugins che possono essere migliorati e versionati come un qualunque software commerciale.

Nel momento in cui un particolare progetto richiede una particolare modifica ad un plugin esistente è possibile definire un plugin di estensione che apporta modifiche dall’esterno senza modificare le logiche esistenti.

Questa architettura è già implementata con successo su JuniorCMS e da oltre un anno ne godiamo i benefici per creare customizzazioni quali:

• aggiunta di campi personalizzati a strutture dati esistenti
• modificare l’interfaccia utente esistente per adeguarla al progetto
• inserire o modificare logica di controllo
• inserire o modificare logica di cooperazione tra plugins (es servizi di sincronizzazione)

Spaghetti Coding Proof:

Ecco le fasi di realizzazione di un Tipico Spaghetti Project:

1. Creazione in velocità di un plugin di gestione rassegna stampa con titolo e file allegato per un cliente.
2. Un nuovo cliente mi chiede la rassegna stampa ma ha bisogno di un campo abstract.
3. Copio il plugin già creato e lo modifico per il nuovo cliente.

Questo tipo di sviluppo lo vedo ogni santo giorno in qualunque realtà aziendale e la triste conseguenza (già citata sopra) è la proliferazione di micro plugins incompatibili tra loro.

La conseguenza più pericolosa è che se il “plugin madre” ha un grosso bug il tempo impiegato per correggere tutti i derivati è semplicemente apocalittico!

Ecco le fasi di realizzazione di un Froggle Spaghetti Project:

1. Creazione in velocità di un plugin di gestione rassegna stampa con titolo e file allegato per un cliente.
2. Un nuovo cliente mi chiede la rassegna stampa ma ha bisogno di un campo abstract.
3. Creo un nuovo plugin che estende la rassegna stampa aggiungendo il campo su db, l’interfaccia e la logica necessaria senza modificare la logica preesistente.

Questo tipo di sviluppo ha enormi vantaggi:

• mi permette di creare soluzioni veloci che possono essere migliorate e redistribuite in tempi più rilassati
• mi permette di gestire la sicurezza del software per singolo plugin senza preoccuparmi delle sue estensioni (che ereditano la sicurezza)
• mi permette di abbattere il numero di versioni incompatibili creando invece “catene di estensione” che possono essere facilmente versionate e mantenute
• mi permette di utilizzare e personalizzare qualunque plugin esistente (anche commerciale) senza violare licenze sul codice o simile.

Sviluppo di FroggleCMS:

1° Ottobre 2010: il devTeam di JuniorCMS da vita allo sviluppo dell’infrastruttura di FroggleCMS (CakePOWER).

1° Novembre 2010: viene rilasciato CakePOWER che implementa su CakePHP l’architettura presentata in questo articolo assieme ad altre architetture di importanza minore.

1° Dicembre 2010: viene rilasciato il plugin “froggle” che contiene l’interfaccia di base di FroggleCMS e la gestione utenti. Questo plugin è destinato ad essere frequentemente aggiornato con l’aggiunta costante delle funzionalità “core”.

1° Gennaio 2011: viene rilasciato il primo pacchetto auto-installante di FroggleCMS pronto per essere utilizzato in attività commerciali.

A questo punto daremo il via ad un programma di sviluppo plugins per coprire in breve tempo le principali esigenze di gestione contenuti on-line quali:

• gestione albero pagine sito web
• gestione news
• gestione rassegna stampa
• gestione calendario eventi
• gestione photo-gallery
• gestione prodotti generici
• gestione pagamento con carta di credito
• organizzazione dei prodotti per categorie
• gestione di un carrello elettronico complesso
• e-commerce (unisce precedenti plugins aggiungendo gestione sconti, gestione coupon, offerte, tasse, valute, magazzino, etc)

Il mercato di riferimento per questo prodotto è il nostro bel paese dunque tutta la documentazione sarà inizialmente prodotta in italiano mentre i commenti del codice sorgente cercheranno, per quanto possibile, di essere scritti in un decente spaghetti-english.

Ciao a tutti e buona fortuna al DevTEAM!

Segnala presso:

La mia esperienza nello sviluppo di applicazioni web (siti web, gestionali, piccole utility) mi ha portato ad elaborare alcune definizioni che utilizzerò nei successivi articoli di analisi:

• framework: è l’insieme di strumenti che consentono di enunciare le istruzioni logiche che compongono l’applicazione.
• applicazione: è l’insieme delle istruzioni necessarie a definire la logica astratta di un software.
• interfaccia: è lo strumento di comunicazione tra l’applicazione e il suo utente.
• prodotto: è l’insieme di applicazione e interfaccia cui vengono applicate delle personalizzazioni specifiche per la singola realizzazione.

Nell’immagine precedente la linea rossa rappresenta la separazione logica tra sviluppo dell’applicazione e lo sviluppo del prodotto.

L’applicazione è costituita di istruzioni logiche generiche che possono descrivere una soluzione software ad un problema collettivo. Lo sviluppo del prodotto si concentra sulla selezione delle applicazioni necessarie e sulla definizione di un insieme di regole di personalizzazione.

Nel momento in cui ci viene richiesto lo sviluppo di un prodotto (es un sito web) dobbiamo soffermarci e ragionare sulle applicazioni che lo compongono: gestione utenti, gestione pagine, gestione news, photo gallery e sulle regole di personalizzazione che lo completano: template grafico, numero di news per pagina, gestione dei menus.

Diventa facile capire che l’obiettivo è spostare la line rossa in modo che l’area di configurazione occupi sempre meno spazio nella costruzione di un prodotto. Il tempo che dedichiamo alla costruzione di un prodotto dev’essere concentrato sulla soddisfazione delle personalizzazioni richieste e non sullo sviluppo delle funzionalità

Il compito del framework:

La realizzazione pratica di quanto illustrato espone alcuni prerequisiti fondamentali che il framework deve soddisfare:

• Tutte le operazioni di configurazione devono poter essere descritte su files fisicamente distinti dai sorgenti dell’applicazione.
• I moduli applicativi (plugins) che compongono l’applicazione devono poter interoperare al fine di estendere e/o modificare il comportamento di altri moduli.
• I moduli applicativi devono essere sensibili ad un sistema di configurazione strutturato e scalabile.
• I moduli applicativi devono erogare funzionalità logiche “dropIn”. Non deve essere richiesta modifica dei files sorgenti!

CakePOWER: un po’ di pepe a CakePHP!

CakePOWER è il progetto che mira a concretizzare l’area core dell’immagine qui sopra fornendo tutti gli strumenti necessari allo sviluppo di plugins (moduli applicativi) al fine di vendere prodotti (siti web e gestionali applicativi) la cui caratteristica principale è alta qualità a basso costo.

Ho iniziato cercando un framework (PHP) che implementi il paradigma MVC e la scelta è ricaduta su CakePHP in quanto progetto abbastanza maturo e direzionato sulla creazione di automatismi che permettono di sviluppare il più velocemente possibile.

CakePOWER sarà sviluppato come un’estensione di CakePHP la quale integra funzionalità complesse nel framework. Di fatto tutto il sorgente sarà contenuto nella folder cake_power e l’integrazione avverrà mediante poche semplici istruzioni da inserire nei files di configurazione principali dell’applicazione.

CakePOWER è un’estensione, non un fork!

Lo stato attuale del progetto è pressochè nullo: sto scrivendo la documentazione delle prime strutture logiche che comporranno CakePOWER. La scelta di sviluppare prima la documentazione è fondamentale per garantire la qualità del codice prodotto.

A breve i sorgenti saranno disponibili su Google Project (http://code.google.com/p/cakepower/).

Segnala presso:

In questo articolo spiego come è possibile utilizzare dei layout contenuti in uno specifico plugin utilizzando quindi il concetto stesso di plugin per re-distribuire contenuti grafici oltre alle funzionalità contenute in helpers e components.

All’interno di un metodo di controller, appena prima del render (o della conclusione del metodo) è sufficiente specificare plugin e layout che si desidera utilizzare per il rendering della richiesta:

...
$this->plugin = 'Myplugin';
$this->layout = 'my_layout';
...

Questo tipo di codice produce la richiesta del file: “/app/plugins/myplugin/views/layouts/my_layout.ctp” da utilizzarsi come layout per la richiesta in corso.

Segnala presso: