Archivio mensile:Agosto 2009

Zend Framework, teoria di base (Controller)

Zend Framework Logo

Continuo a studiare e fare ordine nella mia testa.

I modi di instradare una richiesta (indirizzo web URI) verso il codice che svolgerà le funzioni necessarie a soddisfarla sono essenzialmente 2:

  • Page Controller
    Questa tecnica prevede l’uso di file separati, uno per ogni pagina (index.php, news.php, articoli.php, ecc.). Il controllo dell’applicazione risulta quindi decentralizzato in differenti files separati.
  • Front Controller
    Questo tipo di controller invece convoglia le richieste verso un unico file (solitamente index.php) che determina quale codice eseguire attraverso diversi sistemi.

Chi ha iniziato a programmare in PHP diversi anni fa non avrà difficoltà a ricordare quando tutto veniva smistato secondo la logica del Page controller. Zend Framework invece, come abbiamo già visto in precedenza, oltre al pattern MVC (Model View Controller), implementa anche il Front Controller pattern per rispondere alle richieste effettuate.

Il componente Zend_Controller è quello che si occupa di tutto ciò. E’ costituito dal Front Controller, dall’Action Controller e da altre classi di supporto.
Come abbiamo visto ogni richiesta effettuata al server web viene inoltrata ad un unico file (denominato “entrance point”, solitamente il nostro index.php) il quale avvia il Front Controller che ha il compito di identificare l’azione e il comando da eseguire in base all’URI richiesto. In Zend Framework questo controller è composto da due componenti essenziali: il router e il dispatcher. Il router determina quale azione deve essere chiamata e il dispatcher esegue la chiamata. Il tutto passa in mano all’Action Controller che si interfaccia a Model e View per costruire la risposta da fornire all’utente.

Vediamo ora nel dettaglio le varie fasi di avanzamento del Controller dello Zend Framework.

Request

E’ una qualsiasi richiesta HTTP che giunge al nostro web server. Viene incapsulata nella classe Zend_Controller_Request_Http che ne memorizza ogni dato (le nostre “vecchie” variabili $_GET, $_POST, $_COOKIE, $_SERVER e $_ENV). Zend Framework fornisce una serie di funzioni in grado di leggere e manipolare questi dati.

Router

La Request viene poi passata al Router che determina quale codice andrà eseguito. Il suo lavoro si basa essenzialmente sull’URI, che viene scomposto e interpretato, e giunge al termine quando vengono identificate le procedure da eseguire. Anche qui il Framework è farcito di una serie di classi che permettono di interagire direttamente con il router per poter arrivare anche a riscrivere parte del suo lavoro (Zend_Controller_Router_Rewrite).

Dispatch

Le procedure che andremo a creare per il nostro applicativo sono classi che estendono il componente Zend_Controller_Action. Ogni classe quindi identificherà un controller e i suoi metodi saranno le varie action da eseguire. Il Front Controller, una volta identificati controller e action, avvia il processo di dispatch che eseguirà le seguenti azioni:

  • caricare il controller (la classe definita da router)
  • istanziare la classe
  • invocare l’action (il metodo della classe definito da router)

Fatto ciò il dispatcher passerà il controllo dell’esecuzione alla classe dell’Action controller.

Action

Le Action sono tutte classi che dovranno essere derivate dalla principale Zend_Controller_Action. Ogni classe avrà a disposizione la Request (da cui leggere eventuali dati), la Response (per scriverli), le View (per la gestione delle viste dell’output) e i Model (per interfacciarsi al Database, ad esempio).
Una caratteristica fondamentale e molto utile delle Action è la possibilità di redirezionare tra loro le varie action (metodi delle classi) tra loro. In pratica possiamo far eseguire più di un action alla volta al nostro controller senza dover ricaricare la pagina.

Oltre alle singole azioni (metodi) che andremo a creare per ogni classe è possibile servirsi di alcuni metodi particolari che verranno eseguiti in momenti specifici: init() al momento in cui viene istanziata la classe, preDispatch() prima di eseguire il metodo, postDispatch() al termine delle operazioni svolte dal metodo. init() risulta particolarmente comodo nelle classi in cui decidiamo che potranno essere eseguite diverse action. In questo caso init() verrà eseguito una sola volta mentre il preDispatch() più volte, prima di ogni azione.

Una volta terminata l’esecuzione della/delle Action necessarie l’output che è stato generato viene inviato al client tramite il Response.

Response

Il Response è una sorta di contenitore nel quale andremo a caricare tutto l’output che invieremo all’utente. Se stiamo parlando di una risposta Web  l’oggetto del response sarà un’istanza del componente (classe) Zend_Controller_Response_Http.
Questo oggetto contiene tre tipi di dati:

  • Headers
    Non quello della pagina HTML bensì un header HTTP nel caso di una pagina Web
  • Body
    Nel caso di pagina web sarà appunto l’intero codice HTML che comporrà la pagina
  • Exception
    Per la gestione degli errori

E’ importante sottolineare che il response potrà essere di diverso tipo e non solo HTML (XML, PDF, ecc.). Il modello MVC infatti prevede che la logica sia separata dall’output (View) e questo, attraverso il response, potrà essere facilmente gestito.

Zend Framework, teoria di base (Componenti)

Zend Framework Logo

Avrei dovuto scrivere questo post all’inizio, forse sarebbe stato il primo di una lunga serie. Lo faccio oggi perchè ho una tale confusione in testa che è necessario mettere ordine. Il modo migliore, come sempre, è quello di scrivere nero su bianco ciò che sei sicuro di aver appreso. In realtà poi, scrivendo, approfondisci e impari cose nuove.

Zend Framework è composto da diversi componenti (Zend_Controller, Zend_Config, Zend_Db, ecc.) che sfruttano famosi ed ultra utlizzati Design pattern (soluzioni condivise a problemi comuni, detta in maniera molto sintetica). Ogni componente comprende diverse altre classi oltre alla principale la quale prende il nome del componente stesso. Zend_Config, ad esempio, contiene Zend_Config_Ini, Zend_Config_Xml e altri. Ognuno di questi componenti secondari può a sua volta contenerne altri. Il nostro lavoro, nella maggior parte dei casi, si interfaccerà ai componenti principali i quali effettueranno chiamate ai secondari a seconda delle nostre richieste ed esigenze. Ovviamente siamo liberi di chiamare qualsiasi componente di qualsiasi livello esso sia.

I componenti di base possono essere suddivisi in 6 gruppi:

Questi sono solo alcuni dell’elenco dei componenti dello Zend Framework. Ne esistono tanti altri e Zend ne sforna dei nuovi quasi ad ogni release. I componenti spesso nascono sulla base delle richieste della community degli sviluppatori che, per stare al passo col web e le sue innovazioni, necessitano sempre più spesso di componenti solidi, testati e stabili.

Vediamo ora una panoramica sui vari gruppi di componenti.

MVC

Questi componenti servono per gestire al meglio il pattern MVC (Model, View, Controller). Tale pattern è nato per separare, durante la scrittura del codice, la logica applicativa (Model e Controller) dalle viste (View).
Il componente Zend_Controller fornisce un ulteriore design pattern, definito Front Controller, che si occupa essenzialmente di svolgere le operazioni di gestione delle richieste effettuate ad un server web.

Fanno parte di questo gruppo poi i componenti Zend_View e Zend_Layout che si occupano di gestire l’organizzazione delle viste. I due componenti coprono ogni esigenza, dalla semplice visualizzazione di un “template” a strutture complesse basate su moduli in cui la pagina viene realizzata mettendo insieme diversi template, magari dove ognuno lavora in propria autonomia.

Internazionalizzazione

Sono una serie di utili componenti che agevolano le operazioni di internazionalizzazione di un sito/applicativo. Sempre più spesso necessitiamo di rendere il nostro sito multilinga (per questo c’è Zend_Transalte) ma non sempre è abbastanza. Un inglese legge e scrive le date in modo diverso da un italiano (Zend_Date) e utilizza una valuta diversa (Zend_Currency). Poi potremmo avere problemi nella gestione dei fusi orari e codici internazionali (Zend_Locale).

Servizi Web

Ogni giorno nascono nuovi siti web potenzialmente destinati al successo. La condivisione dei contenuti tra i diversi siti sta prendendo sempre più piede ed oggi è necessaria. Questi componenti consentono l’accesso ai più famosi servizi web, dai famosi RSS Feed a Google, Yahoo, Amazon, ecc e relative API.

Autenticazione e accessi

Gli utenti accedono ai siti autenticandosi e per ognuno di essi potremmo gestire diversi livelli di interazione. Questi componenti supportano queste operazioni: Zend_Auth, in collaborazione con Zend_Session, è un ottimo strumento di identificazione dell’utente, cosa poi questo potrà fare sul nostro sito lo gestiremo con Zend_Acl.

Comunicazione tra applicazioni

Vale lo stesso discorso della condivisione visto prima per i Servizi Web. Questi componenti, a differenza di quelli di prima, consentono di interfacciarsi ad altri siti web, attraverso il protocollo HTTP (Zend_Http), comunicando con diversi formati di trasferimento dati: XML, SOAP, JSON, ecc.

Core

In questa categoria rientrano tutti gli altri componenti che non hanno un uso specifico come i precendenti. Alcuni di loro ricoprono un ruolo fondamentale (Zend_Db) e nel 99% dei casi ne farete utilizzo. Altri serviranno raramente ma è bene tenere presente che esistono: Zend_Form per una rapida realizzazione di form, Zend_Validate per validare i dati inviati dagli utenti, Zend_Filter per filtrare e sostituire eventuali dati errati, Zend_Mail per inviare in maniera sicura e semplice email, Zend_Pdf per restituire eventuali file in formato PDF, ecc.

Zend_Application, bootstrap semplice e flessibile

Zend Framework Logo

E’ sempre dura abbandonare la vecchia strada per la nuova. Per un annetto buono ci siamo abituati a configurare il Bootstrap a seconda delle esigenze, ognuno secondo i propri criteri (chi tutto in index.php, chi inizializzava una classe denominata Bootstrap, chi la stessa classe la registrava con registerPlugin nel frontController, ecc.). Ora Zend ha ufficializzato la “strada da percorrere” basandosi proprio sulle tante soluzioni “escogitate” dalla community degli sviluppatori. Il nuovo componente Zend_Application è ciò che Zend ha sviluppato come soluzione migliore.
A primo impatto (sto sbattendo la testa contro il muro da diversi giorni) il tutto è un po’ ostico ma ora, studiando con calma la documentazione, inizio a vedere la luce.

In un’applicazione configurata con pattern MVC spesso ci ritroviamo ad eseguire diverse operazioni: setup del database, configurare viste e view helpers, configurare uno o più layout, registrare plug-in, registrare action helpers e tanto altro. Allo stesso tempo potremmo avere un’applicazione complessa che richiama diverse procedure, ma magari non tutte richiedono MVC. Un cronjob per aggiornare giornalmente i dati, ad esempio, non richiede MVC. Lo stesso vale nel caso di eventuali servizi esterni, API, ecc.

Zend_Application ci aiuta a gestire al meglio tutta la fase iniziale di Bootstrap dell’applicativo in modo che questa risulti semplice da gestire, flessibile e quanto più riusabile in altri progetti.
Per iniziare ad utilizzare Zend_Application basta inizializzarlo nel nostro index.php:

/** Zend_Application */
require_once 'Zend/Application.php';
// Create application, bootstrap, and run
$application = new Zend_Application(
APPLICATION_ENV,
APPLICATION_PATH . '/configs/application.ini'
);
$application->bootstrap();
$application->run();

Nel creare una nuova istanza di Zend_Application passiamo 2 parametri:

  • APPLICATION_ENV – (es: production)
  • Path del file di configurazione (può anche essere un array o uno Zend_Config object)

Io, per i file di configurazione, ho sempre utilizzato i .ini e, per ora, continuo su questa strada. 😉
Nel file application.ini possiamo configurare diversi paramentri tra cui quelli relativi al bootstrap stesso. La novità sta nel fatto che ora possiamo richiamare alcune risorse che Zend_Application caricherà automaticamente.

includePaths.library = APPLICATION_PATH "/../library"
bootstrap.path = APPLICATION_PATH "/bootstrap.php"
bootstrap.class = "Bootstrap"
resources.frontController.controllerDirectory = APPLICATION_PATH "/controllers"
resources.db.adapter = "PDO_MYSQL"
resources.db.params.host = "localhost"
resources.db.params.username = "root"
resources.db.params.password = "xxxxxxxx"
resources.db.params.dbname = "myDb"

Con il prefisso resources infatti richiamiamo il FrontController (configurando la controllerDirectory) e il DB con relativi parametri. Tali componenti saranno quindi disponibili nell’istanza di Zend_Application e potranno essere richiamati facilmente in altri “luoghi” dell’applicativo (come lo devo ancora capire bene!).
Vediamo ora come costruire la nostra classe Bootstrap che sarà posizionata in /application/bootstrap.php

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
}

In questo modo avremo un bootstrap che, dopo esser stato inizializzato in index.php, caricherà il frontController e il Database Adapter così come configurati nel file di configurazione (vedi sopra application.ini).
Nel caso volessimo avviare altri componenti (Layout, Auth, Acl, ecc.), classi e quant’altro, Zend_Application può essere sviluppata in questo modo:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initFoo()
    {
        // ...
    }
    protected function _initBar()
    {
        // ...
    }
    protected function _initBaz()
    {
        // ...
    }
}

La classe Bootstrap, estendendo la Zend_Application_Bootstrap_Bootstrap, ci permette di sfruttare una serie di metodi e convenzioni prestabilite. Prima tra tutte, ad esempio, quella che definisce che tutti i metodi protected che iniziano con _init vengono considerate risorse (“resource method“).
Qui viene il bello. Se desideriamo inizializzare una risorsa singola basta passare il nome come parametro del metodo bootstrap() nel file index.php, per due o più risorse basterà passarli con un array, per tutte non passiamo alcun parametro.

$bootstrap->bootstrap('foo'); // solo foo resource
$bootstrap->bootstrap(array('foo', 'bar')); // solo foo e bar resource
$bootstrap->bootstrap(); // TUTTE

In questo modo potremo attivare in modo molto semplice solo le risorse necessarie. Tornando agli esempi iniziali (vedi sopra), nel caso di accesso da parte di cronjob, possiamo far partire un bootstrap ridotto che carica i soli componenti necessari all’esecuzione delle operazioni schedulate.

Torno a studiare… 😉

PHP Excel, la classe migliora notevolmente le performance

phpexcel (codeplex) logo

Utilizzo la classe PHPExcel da un oltre un anno in un progetto sviluppato per Energika. L’anno scorso, dopo aver anche dato il mio piccolo contributo alla classe, il progetto è andato in produzione con la vecchia release 1.6.3

Come spesso accade, quando le cose funzionano, difficilmente si aggiorna una libreria. Si dovrebbe, certo, ma non è sempre così. Se l’aggiornamento richiede modifiche al codice lasci tutto come sta. Se l’aggiornamento rischia di fermare l’azienda non tocchi nulla. Poi mettici il tempo che è sempre meno…
Se invece la richiesta di ottimizzazione del codice arriva direttamente da parte del cliente (sono veramente pochi!) lo fai, eccome!
Ho passato quindi una settimana a rivedermelo per filo e per segno. Tra aggiornamenti, qualche dritta di Maarten e modifiche al codice originario siamo arrivati ad un ottimo risultato: un abbattimento dei tempi del 70% circa!

Come evidenziato nel changelog la nuova classe PHPExcel ultima versione (1.7.0), rilasciata proprio in questi giorni (il 10/08/09), migliora le performance nelle operazione di formattazione delle celle, nello sviluppo delle formule e altre utilissime funzioni.

Dal file changelog 1.7.0:
– Feature:  (MBaker) – New RPN and stack-based calculation engine for improved performance of formula calculation
–   Faster (anything between 2 and 12 times faster than the old parser, depending on the complexity and nature of the formula)
–   Significantly more memory efficient when formulae reference cells across worksheets
….
–   Better trapping/handling of NaN and infinity results (return #NUM! error)
–   Improved handling of empty parameters for Excel functions
– Feature:  (MBaker) – New calculation engine can be accessed independently of workbooks (for use as a standalone calculator)
….
– Feature:  (ET) Work item  9794 – Support arbitrary fixed number of decimals in PHPExcel_Style_NumberFormat::toFormattedString()
– Feature:  (ET) Work item  6857 – Improving performance and memory on data dumps
–    Various style optimizations (merging from branch wi6857-memory)

Aggiornare Twitter da una Pagina Facebook

Aggiornare twitter da facebook

Ho creato e gestisco diverse pagine su Facebook (myGDM, Tresette, Briscola chiamata, Busca) e presto ne aprirò altre due per un nuovo progetto. Le pagine vanno visitate almeno una volta al giorno, bisogna interagire con i propri fans e rispondere alle loro eventuali richieste. E’ il minimo.
Per reperire contenuti da diffondere sulla Bacheca di ognuna di esse uso Google Alert. Ho inserito le mie parole chiave e Google ogni giorno mi invia le novità. Leggo rapidamente di cosa si tratta e se i contenuti meritano li pubblico in bacheca.

In tutto questo turbinio di contenuti finora non ho avuto modo, tempo e idee per aggiornare anche il profilo di myGDM su Twitter. Oggi Michael Gummelt ha trovato una soluzione a questo problema. Sul Blog di Facebook ha annunciato che è disponibile una nuova funzionalità che permette agli amministratori della Pagine Facebook di aggiornare lo status anche su Twitter.

Trovo questa feature molto interessante perchè il tempo è poco e la voglia di condividere sempre tanta, come sottolinea appunto Michael quando scrive: “Many people have asked us to make Facebook and Twitter work better together for those times when they want to share their content as widely as possible.

Come aggiornare Twitter da una Pagina Facebook

E’ veramente semplice. Dopo essersi loggati su entrambi i siti (sia Facebook che Twitter) andate nella pagina Facebook to Twitter. Qui apparirà l’elenco delle pagine da voi gestite (dovete essere Amministratori) e, affianco ad ognuna, vedrete il pulsante Collegati a Twitter. Cliccando verrete direzionati su Twitter dove vi apparirà la schermata qui sotto.

twitter application allow deny

E’ necessario cliccare su Allow per permettere a Facebook di accedere direttamente al nostro account Twitter. Dopo aver cliccato verrete direzionati (appare “Redirecting you back to the application“) nuovamente nella pagina Facebook to Twitter che evidenzierà la connessione tra i due siti.

facebook page to twitter

La pagina ora è collegata e non resta che selezionare quale tipo di contenuto dovrà essere inviato a Twitter. Come vedete nell’immagine le opzioni possibili, al momento, sono:

  • Aggiornamenti di stato (status)
  • Foto
  • Link
  • Note
  • Eventi

Non credo che vi siano altre opzioni disponibili (quelle di altre applicazioni installate, ad esempio). Ho provato con una pagina sulla quale installo le applicazioni per provarle e le opzioni disponibili erano comunque quelle evidenziate qui sopra.

A questo punto siete pronti per condividere ciò che pubblicate su Facebook direttametne anche su Twitter.
Buona condivisione!

Riotta e la Social Media Revolution

Social Media Revolution

Ogni mattina, prima di iniziare a “vivere” la giornata, faccio sempre una puntatina sulla Home di Twitter. Stamattina mi ha colpito in particolar modo un tweet di _arianna che linkava il video Social Media Revolution scrivendo “Non ditelo a Riotta“. La cosa non poteva di certo passare inosservata dopo le dichiarazioni di quest’ultimo su Internet e sulla blogosfere, “luogo” di cui si vanta per esser stato il primo giornalista a metterci piede ma anche il primo ad uscirne (“Tal cred!” direbbero a Reggio, “Eh grazie ‘o ca…” invece a Napoli).
Per farla breve, ho cliccato e mi sono guardato il Social Media Revolution. Bello, consiglio la visione.

Il frame di cui riporto qui sopra l’immagine è un concetto semplice, quasi scontato, ma altrettanto fenomenale. Effettivamente non ci avevo mai fatto caso: Facebook, se fosse un paese, sarebbe il 4° al mondo come numero di “abitanti”. Quarto dopo Cina, India e Stati Uniti.

Social Media Revolution

Riotta

Vi riporto alcune perle:

  • sono stato il primo giornalista italiano ad aprire un Blog, sono stato il primo giornalista italiano a chiuderlo
  • 6 miliardi di abitanti, 6 miliardi di blog, ognuno si scrive il suo, io mi scrivo il mio, Enrico si scrive il suo, voi vi scrivete il vostro e non ci leggiamo più! E’ una relazione assolutamente monogamica.
  • se guardate i commenti in un qualsiasi giornale italiano i commenti dei lettori sono tutti deficenti, sono commenti scemi perchè l’anonimato tira fuori il peggio di ognuno di noi
  • Internet è diventata una specie di grande camera oscura dove, siccome non sei responsabile di quello che dici, tiri fuori il peggio di te … usi la pancia anzichè la testa

PHPMailer multi lingua

Finalmente, prima di partire per le ferie, sono riuscito a mettere insieme un pò di “pezzi” di codice utilizzati nei diversi siti in lingua che ho realizzato. Ne è saltata fuori una classe PHP che pubblico sotto licenza GNU License.

La classe estende l’ultra famosa ed utilizzata PHPMailer class.
Lo scopo è quello di poter configurare rapidamente l’invio di email in lingua (Subject e Body). Attraverso l’utilizzo di questa classe infatti basteranno poche chiamate per poter inviare i messaggi a seconda della lingua selezionata. Ho implementato infatti un metodo dinamico (tramite overloading __call) per la selezione del testo (body) da inviare.

Per maggiori dettagli visita la pagina dedicata (English) alla MyPHPMailer multi Language Body Class.

Online il sito del Comitato a sostegno di Carlo Pedemonte (Genova)

Era da tempo che suggerivo a Carlo Pedemonte, responsabile del Sistema Informativo dell’Ospedale Sampierdarena “Villa Scassi” (Genova) dal 1990, di “aumentare” la sua visiblità online e, soprattutto, di mettere a disposizione della rete tutto il materiale necessario. Oggi mi ha scritto segnalandomi che, finalmente, il “Comitato a sostegno di Carlo Pedemonte“, nato ad Aprile 2009, ha pubblicato online il sito ufficiale.

Il “Comitato a sostegno di Carlo Pedemonte per la difesa della legalità e contro gli sprechi nella sanità pubblica ligure” nasce ufficialmente il 20 aprile 2009, costituito da cittadini genovesi che da tempo stanno seguendo approfonditamente le vicende che ruotano attorno al dirigente informatico della ASL 3 di Genova.
Il Comitato si prefigge quindi di appoggiare e sostenere l’impegno di Carlo Pedemonte e informare i cittadini riguardo alla gestione dell’informatica sanitaria ligure e riguardo all’evolversi della vicenda (esposti, inchieste giudiziarie, atti della Pubblica Amministrazione).

Bravo Carlo!
Come ti dicevo è importante che tu sia visibile, il resto lo farà la rete. E’ molto potente e non perdona.
Avanti così!