Articoli marcati con tag ‘rad’

Quest0 articolo segna l’inizio di una serie di considerazioni e analisi il cui obiettivo è la progettazione e costruzione di un framework applicativo web based.

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/).

CakePHP 1.2 introduce una serie di funzionalità dedicate esplicitamente allo sviluppo RAD di applicazioni.

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.