Come Adapter per Zend_Translate prediligo gettext, con Poedit si lavora molto bene!

In fase di deploy di un’applicazione, dopo aver tradotto i miei file, mi sono accorto che mancavano le traduzioni dei messaggi di errore di Zend_Validate (Alpha, EmailAddress, StringLength, ecc.). Dopo un po’ di ricerche ho scoperto che esiste una directory resources/languages (solo nella versione full di ZF) in cui risiedono tutti i file con le traduzioni dei suddetti messaggi di errore.

Il file però presenta le traduzioni in un array e quindi ho dovuto generare un testo da integrare nel file .po
Per fare ciò ho utilizzato queste semplici 2 righe di codice:

foreach($myAr AS $en => $it)
{
echo ‘msgid “‘ . $en . “\”\n”;
echo ‘msgstr “‘ . $it . “\”\n”;
echo “\n”;
}

Dove ovviamente $myAr è l’array che trovate nei vari file di traduzioni (i file si chiamano Zend_Validate.php).
Ho creato così un nuovo Catalogo di Poedit, poi l’ho aperto con un Editor di testo e ho incollato dentro il risultato visualizzato nel browser dalla suddetta procedura. Aprendolo con Poedit e salvando il gioco è fatto!

Potreste incontrare problemi (a seconda del SO e dell’Editor che usate) sulla codifica dei file. A me, ad esempio, Poedit è andato in errore perchè il file, una volta salvato con l’Editor, aveva perso la codifica UTF-8. Per fortuna l’editor del Mac (TextEdit) permette di scegliere la codifica in fase di salvataggio. Ripristinato l’UTF-8 tutto è filato liscio.

Esistono diversi metodi comunque per convertire la codifica dei file di testo (UTF-8).

E’ da ieri che sbatto la testa su questo problema!
Sul mio server di sviluppo tutto ok, nessun problema. In ambiente di produzione invece riscontro un problema col quoting dei campi passati dalle form create con Zend_Form. Appena aggiungo le virgolette (“) la procedura di salvataggio dati me li quota (\”) e non capivo il perchè!

Il problema sta nell’impostazione magic_quotes_gpc del PHP.
Sul server in produzione infatti questo è settato a On. Ecco la differenza tra l’ambiente di sviluppo (su cui è Off, infatti monta PHP 5.3.x) e quello in produzione (PHP 5.2.x). A questo punto le alternative per risolvere il problema sono diverse.

Una soluzione è disabilitare tale impostazione via file .htaccess inserendo in questo file la riga:

php_flag magic_quotes_gpc Off

In alternativa, ove questo non sia possibile, consiglio l’utilizzo dell’ottimo Filter_StripSlashes creato e descritto da Phil Brown.

Che oggi la codifica Unicode (UTF8) risolva una marea di problemi sull’utilizzo delle diverse lingue è risaputo. Se impostate un sito con questa codifica è tutto più semplice.

Oggi però avevo necessità di scrivere alcuni caratteri direttamente nel codice tramite l’editor Eclipse. Scriverlo lo scriveva ma quando provavo a salvare mi dava questo errore:

Per risolvere basta cambiare la codifica del file in uso.
Dal menù Edit -> Set Encoding…
Si apre questa finestra (vedi sotto), selezionate Other e poi UTF-8.

Il “problema” è risolto!

Non è stato semplice saltarci fuori, per una serie di motivi. La conversione di un numero binario (o esadecimale) ad un numero in virgola mobile non l’avevo mai affrontato perchè in PHP, solitamente, si lavora con numeri “definitivi” (integer, float, ecc). Tale conversione può dipendere da diversi fattori.

Per prima cosa ho dovuto studiarmi un pò lo standard IEEE 754, in particolare i numeri a precisione singola (32 bit). Su Wikipedia è spiegato molto bene il metodo con cui effettuare la trasformazione (esponente, mantissa, ecc). Devo ammettere che prima di trovare il codice “giusto” mi sono imbattuto in diverse librerie che non davano l’esito atteso. Alla fine ho trovato una semplice funzione sul sito PHP nella pagina dedicata al Floating point numbers. Leggendo un po’ di commenti ho trovato l’ottimo intervento di info at forrest79 dot net.

Riporto qui di seguito la funzione completa:

function binToFloat($bin) {
if(strlen($bin) > 32) {
return false;
} else if(strlen($bin) < 32) {
$bin = str_repeat('0', (32 - strlen($bin))) . $bin;
}
$sign = 1;
if(intval($bin[0]) == 1) {
$sign = -1;
}
$binExponent = substr($bin, 1, 8);
$exponent = -127;
for($i = 0; $i < 8; $i++) {
$exponent += (intval($binExponent[7 - $i]) * pow(2, $i));
}
$binBase = substr($bin, 9);
$base = 1.0;
for($x = 0; $x < 23; $x++) {
$base += (intval($binBase[$x]) * pow(0.5, ($x + 1)));
}
$float = (float) $sign * pow(2, $exponent) * $base;
return $float;
}

Per testare il tutto dovreste poter effettuare la seguente conversione:

Bin: 1000011100010111110001111010101
(Bin Corretto: 01000011100010111110001111010101)
Float: 279.77993774414

N.B.: Come potete vedere la funzione aggiunge il primo bit (0) nel caso in cui l’intero binario sia composto da 31 bit e non 32.

Sono alle prese da diversi giorni con un problema da risolvere per un nuovo progetto che porterò avanti nei prossimi mesi. Dopo aver sbattuto un po’ la testa sul Modbus, il protocollo di comunicazione dei PLC, sono alla ricerca di una soluzione che mi permetta di effettuare chiamate ad uno slave da ambiente PHP. Il risultato della chiamata Modbus quindi deve essere disponibile direttamente nel codice PHP.

Le diverse soluzioni che sto analizzando sono:

1. Scrivere un’estensione per PHP che, grazie ad una libreria Libmodbus, possa effettuare chiamate direttamente dal codice PHP
2. Utilizzare un Gateway Modbus TCP/IP- RTU. In pratica dal codice PHP potrei effettuare una chiamata al gateway tramite socket. Il gateway a sua volta gestirebbe la chiamata al device via Modbus e restituirebbe i dati alla mia procedura PHP.
3. Utilizzare un software open source tipo SCADA. Ad esempio Likindoy o OpenSCADA.

La soluzione migliore, in termini di sviluppo, come sempre deve essere la più semplice da implementare e manutenere. Al momento sono orientato sulla 1, la 2 ho problemi a compilarla e la 3 l’ho parcheggiata in attesa di testarla.
Vi farò sapere…

Lo sviluppo di un’applicativo e-commerce B2B per un cliente mi ha portato ad analizzare a fondo il Payment Gateway del Consorzio Triveneto S.p.A. Prima di iniziare mi complimento con il consorzio per aver redatto una documentazione molto precisa. Lo stesso gateway lo trovo veramente ben fatto ma su questo potrò darvi maggiori dettagli tra qualche mese, quando il cliente sarà in produzione.

Introduzione

In un’applicativo web-based di e-commerce solitamente le figure (sarebbe meglio parlare di macchine, PC, server, ecc.) con cui abbiamo a che fare sono tre:

1. L’utente che acquista e che naviga il sito (definito Cardholder)
2. Il negozio online: il server del sito di e-commerce (definito Merchant)
3. Il Gateway per i pagamenti, in parole povere: il server che si occupa delle transazioni con carta di credito (denifito Payment Gateway, qui di seguito Gateway)

Dal punto di vista pratico quindi avremo il Cardholder che naviga il sito del Merchant ed esegue le sue operazioni di acquisto (ordini, carrello, ecc.). Una volta terminata la sessione di acquisti si dirige alla pagina del pagamento e qui entra in azione tutto quello che vedremo in questo Tutorial.

L’intero processo prevede comunicazioni tra le tre figure sopra elencate. Le comunicazioni tra Merchant e Gateway possono essere definite server-to-server, l’utente infatti non sempre interagisce con esse. I server si scambiano messaggi tra loro per ovvi motivi di sicurezza.

Sulla pagina del Merchant quindi deve essere predisposta una pagina che si occupa di inviare i dati (codice identificativo, importo da pagare, numero ordine, ecc.) al Gateway. Quando il Cardholder clicca sul famoso “Paga ora!” tali dati vengono inviati al server del Gateway che, dopo averli elaborati e controllati, restituisce una risposta al server del Merchant. In questo frangente il Cardholder resta in attesa davanti al pc!
Una volta ricevuta la risposta dal Gateway la nostra procedura (Merchant) elabora i dati ricevuti e decide se proseguire o meno. In caso di errori potrebbe visualizzare una pagina al Cardholder perchè qualcosa è andato storto, in caso sia tutto ok invece potrebbe direttamente redirezionare il Cardholder verso la HPP (pagina del Gateway su cui l’utente inserisce i dati della sua carta di credito).
Questa prima transazione (e relativo scambio di messaggi), nel modello predisposto dal Consorzio Triveneto, prende il nome di PaymentInit.

Il nostro utente (Cardholder) quindi, se i dati passati al Gateway sono congrui, viene redirezionato sulla HPP dove potrà inserire i dati della sua carta di credito. L’utente effettua quindi l’operazione compilando tutti i campi e poi dà l’invio.
Qui scattano nuovamente diverse comunicazioni prima di restituire l’esito al Cardholder.
Per prima cosa il Gateway deve interfacciarsi a sua volta ad altri server, quelli del Centro autorizzativo, e verificare la validità della carta, la disponibilità e quant’altro. Eseguita questa operazione ricontatta il Merchant riportando l’esito dell’operazione che, anche questa volta, può essere positivo o negativo. In base all’esito il server del Merchant restituisce un URL verso cui redirezionare il Cardholder. Il Gateway quindi si occupa poi di redirezionare il Cardholder sulla pagina dell’esito.
Questa seconda transazione (e relativo scambio di messaggi), nel modello predisposto dal Consorzio Triveneto, prende il nome di NotificationMessage.

Ora passiamo alla pratica, successivamente vedremo perchè il NotificationMessage è così importante dal punto di vista della sicurezza.

La Classe PgConsTriv

Ho implementato questa classe e l’ho rilasciata sotto licenza GNU Lesser General Public License su SourceForge.
Questa la pagina che ho predisposto per la documentazione tecnica per la classe PgConsTriv e qui link per il download dell’ultima release (PgConsTriv.zip).
Insieme alla classe trovate una cartella example, in cui risiedono i file di esempio che vedremo insieme in questo Tutorial, e il file di configurazione. In dettaglio:

• PgConsTriv.php (classe)
• PgConsTriv.inc.php (file di configurazione)
• example/
  • paynow.php
    Pagina per predisposizione e invio del PaymentInit
  • responseURL.php
    Pagina per ricezione ed elaborazione del NotificationMessage
  • errorURL.php
    Pagina per esito negativo
  • goodURL.php
    Pagina per esito positivo
  • test_PG.php
    Form che invia POST per testare la pagina del Response URL

Prima di iniziare dovete configurare i parametri della classe presenti nel file PgConsTriv.inc.php

Il PaymentInit e l’inizio della transazione

Come dicevamo sopra, tutto ha inizio con l’invio da parte del Merchant del PaymentInit. Da questo riceveremo una prima risposta che ci fornirà:

• In caso di esito positivo: l’indirizzo verso cui redirezionare il Cardholder e il PaymentID
• In caso di esito negativo: una stringa con !ERROR! e relativa descrizione

Analizziamo ora il file paynow.php in dettaglio.

N.B.: Preferisco creare una pagina separata alla quale passo via GET l’id dell’ordine. Tramite questo recupero dal database tutti i dati necessari dell’ordine e avvio la procedura. In questo modo si ha una maggiore sicurezza perchè se, ad esempio, invio tutti i dati via POST o GET direttamente alla pagina l’utente “furbetto” potrebbe intercettarli e variarli.

Al paynow.php quindi arriva il mio id ordine ($idp), poi recupero i dati dal database e li sistemo in un array ($arRp).
A questo punto verifico i dati e decido se procedere o meno:

// VERIFICO se può accedere all'ordine
if( count($arRp) > 0 &&
$idp > 0 &&
isset($arRp["stato"]) &&
($arRp["stato"] == "NEW" || $arRp["stato"] == "PAYMENT_INIT" )
) {

N.B.: Nel mio ordine gestisco un campo stato. E’ lo stesso che poi andrò ad aggiornare tramite risposte del server del Gateway in base ai vari esiti e passaggi. In questo modo avrò sempre sotto controllo l’andamento dell’ordine.
Qui sopra, infatti, verifico che lo stato sia consono a ciò che sto per effettuare: il PaymentInit. Il mio ordine quindi deve essere o in stato Nuovo (NEW) o in PaymentInit. Questo secondo caso lo lascio passare perchè ipotizzo la situazione in cui l’utente clicca su “Paga ora!” e, dopo aver visualizzato la HPP del Gateway, chiude il browser.

A questo punto siamo pronti per inviare il PaymentInit che altro non è che l’invio di una serie di dati via POST ad un indirizzo specifico. Creando un’istanza della classe andremo ad inserire i soli dati che potranno variare da ordine ad ordine mentre tutti gli altri dati saranno gestiti dalla classe stessa.
Vediamo ora l’istanza della classe e la preparazione del PaymentInit con l’invio dei dati al Gateway.

// init PgConsTriv Class
$pg = new PgConsTriv($lng);
$pg->setAction('Purchase');
$pg->setSecurityCode_PI( $secCode );
$pg->sendVal_PI($importo, $idp);

Per istanziare la classe devo passare il parametro della lingua ($lng). Tale parametro è opzionale e nel caso non venga passato la classe utilizzerà la lingua di default settata nel file di configurazione. Per maggiori dettagli leggi il Tutorial multi lingua.
Il metodo setAction imposta l’Action. Purchase si occupa di eseguire direttamente l’accredito dell’importo (vedi documentazione del Gateway, Appendice A).

Veniamo ora al discorso sicurezza e il parametro SecurityCode.

N.B.: Nella documentazione del Consorzio (pag. 23) si raccomanda di verificare sempre l’autenticità del NotificationMessage. Una delle soluzioni proposte è quella di inviare via PaymentInit un valore che il Cardholder non vede e non può conoscere. Lo stesso valore verrà poi restituito al Merchant successivamente attraverso il NotificationMessage. In questo modo potremo verificare il dato ricostruendolo e confrontandolo con quello passato dal NotificationMessage.

Impostiamo quindi il nostro SecurityCode ($secCode). Per generare un codice univoco potreste crearvi una stringa criptando in md5 alcuni dati presenti nel database (es: data ordine, idordine, importo, ecc.). In questo modo, successivamente, all’arrivo del NotificationMessage sarete in grado di ricostruirla con la stessa logica e verificarla con quella che vi verrà passata dal Gateway.

A questo punto punto siamo pronti per inviare il PaymentInit. Il metodo sendVal_PI riceve 2 valori:

• $importo – Importo della transazione
• $idp – Denominato trackid nella Documentazione del Gateway e deve essere un id univoco dell’ordine

Il metodo sendVal_PI invia i dati al Gateway e ne elabora la risposta.
Ora vediamo come gestire tale risposta:

// Verifico esito del PaymentInit
if( $pg->hasError_PI() )
{
// SEGNALAZIONE ERRORE!
echo "<h1>ERRORE: ".$pg->getError_PI()."</h1>";
} else {
// Registro il PaymentID nel database e invio l'utente alla HPP del Gateway
mysql_query("UPDATE ordini SET .... ....");
header("Location: " . $pg->getPaymentURL_PI() );
}

Il metodo hasError_PI ci restituisce true se si sono verificati errori, in tal caso l’errore lo possiamo recuperare con il metodo getError_PI.
In caso di esito positivo recuperiamo i dati con:

• getID_PI – PaymentID generato dal Gateway
• getPaymentURL_PI – URL della HPP

Redirezionando l’utente verso la HPP del Gateway abbiamo concluso le operazioni del PaymentInit. Il Cardholder (utente) caricherà tale pagina e potrà inserire i dati della sua carta di credito. Solo dopo che avrà dato l’invio sulla HPP il Gateway ci contatterà per inviarci il NotificationMessage.

Il NotificationMessage e la chiusura della transazione

Nel momento in cui l’utente invia i dati della sua carta di credito al Gateway questo, dopo averli controllati presso il Centro Autorizzativo, contatta il server del Merchant inviando il NotificationMessage. Il Merchant risponde con un stringa che include l’indirizzo verso cui redirezionare il Cardholder.
La pagina di esempio che si occupa di tutto ciò è responseURL.php.

La prima operazione è creare una nuova istanza della classe per poi passargli i dati ricevuti via POST.

// init PgConsTriv Class
$pg = new PgConsTriv($lng);
$pg->setAction('Purchase');
$pg->setVal_NM($_POST);

setVal_NM si occupa appunto di registrare tutti i dati nella classe.
A questo punto iniziamo i nostri controlli per verificare la validità dei dati ricevuti.

// get paymentid
$paymentid = $pg->getPaymentID_NM();
// Verifico se esiste il PaymentID
if( $paymentid !== false ){
// Recupero Ordine dal database in base al PaymentID settato in fase di PaymentInit

Nel caso in cui qualcosa fosse andato storto o il PaymentID non risulta correttamente impostato il valore restituito da getPaymentID_NM è false. Lo verifichiamo e proseguiamo.
A questo punto posso recuperare i dati dell’ordine agganciando il PaymentID che mi ero registrato nel database in fase di PaymentInit. Recuperando i dati dal DB posso generare nuovamente il SecurityCode e verificarlo:

// set Security Code per verifica validità del Notification Message
$pg->setSecurityCode_PI( $secCode );
// Verifico autenticità del NotificationMessage
if( $pg->isValid_NM() ) {

Il metodo isValid_NM si occupa della verifica del SecurityCode. Controlla quello passato dal metodo setSecurityCode_PI con quello appena ricevuto dai dati POST.
Una volta superata questa verifica i nostri dati sono stati validati e possiamo ora procedere alla verifica dell’esito della transazione.
Nel caso abbia avuto esisto positivo avremo:

# Transazione Elaborata
if( $pg->isTransGood_NM() &&
$arRp["stato"] == "PAYMENT_INIT" &&
$pg->getVal_NM("trackid") == $idp // Verifico idp
) {
// OK, Registro STATO e dati TRANSAZIONE nel DB
$stato = $pg->getVal_NM("result");
$TranID = $pg->getVal_NM("tranid");
$Auth = $pg->getVal_NM("auth");
mysql_query("UPDATE .... SET ....");
// Verifico se elaborare l'ordine o meno a seconda del campo result

Per prima cosa verifichiamo con isTransGood_NM l’esito positivo della transazione. Poi (vedi documentazione del Gateway a pag.18) controlliamo che effettivamente sia il primo NotificationMessage che riceviamo. Potrebbero verificarsi dei casi in cui ne vengono inviati anche più di uno. La documentazione a riguardo dice di considerare attendibile sempre e solo il primo. Noi quindi, verificando lo stato, ci assicuriamo di ciò (lo stato infatti viene poi modificato e il secondo eventuale NotificationMessage non passa). Superati questi controlli possiamo prelevare i dati con il metodo getVal_NM (vedi documentazione del Gateway per elenco dei campi disponibili).

Attenzione: fino ad ora abbiamo parlato di esito della transazione. Parliamo in termini di elaborazione effettuata e non di effettivo accredito dell’importo prelevato dalla carta di credito (esito dell’acquisto). Per questo esistono altri metodi che controllano il campo result dei dati inviati tramite NotificationMessage.
I metodi sono diversi in base al valore che il campo result può assumere:

• isCaptured_NM()
• isNotCaptured_NM()
• isApproved_NM()
• isNotApproved_NM()
• isDeniedByRisk_NM()
• isHostTimeout_NM()

Nel nostro caso (Action = Purchase) il valore che corrisponde all’effettivo accredito dell’importo è “CAPTURED”.

Nel caso in cui la transazione invece dovesse avere esito negativo la funzione isTransError_NM restituisce true e noi possiamo procedere alla registrazione dell’errore nel DB:

# Transazione NON Elaborata a causa di errori tecnici
if( $pg->isTransError_NM() ) {
// ERROR, Registro Errore nel DB

Anche in questo caso registro comunque lo stato ERROR nel campo del mio ordine (questo per quanto spiegato sopra sul discorso di un eventuale doppio NotificationMessage) e anche l’eventuale errore recuperato con getVal_NM(“ErrorText”).
A questo punto non resta che comunicare al Gateway l’URL verso cui deve redirezionare il Cardholder:

// Restituisco al Gateway l'URL su cui redirezionare il Cardholder
echo "REDIRECT=". $pg->getURL_NM();

Il metodo getURL_NM restituisce il goodURL o errorURL a seconda che l’esito della transazione sia positivo o negativo. Esso considera inoltre, in base all’action impostato, anche l’esito dell’acquisto (accredito importo).

A questo punto si concludono anche le operazioni del NotificationMessage.
Resta un’ultima considerazione da fare come ben rappresentanto nella documentazione del Gateway (pag. 23).

Se il NotificationMessage non viene eseguito regolarmente

Cosa accade se, ad esempio, il Gateway invia il messaggio ma per qualsiasi motivo il server del Merchant non lo riceve?
In questo caso, sia che la transazione abbia esito positivo, sia negativo, il Gateway reindirizza il Cardholder verso la pagina ErrorURL. In questo caso l’utente vede esisto negativo mentre la transazione magari è andata a buon fine e, ad esempio, anche l’esito dell’acquisto è positivo (con tanto di accredito dell’importo).
Come da documentazione:

E’ quindi importante che il Merchant prepari l’ErrorURL in modo tale da ricavare informazioni utili per poter investigare l’accaduto e informare successivamente il Cardholder sull’esito dell’acquisto.

- -

Bene, siamo giunti alla fine del Tutorial.
Spero di implementare presto anche la tipologia di messaggio Payment (per operazioni in differita tra Merchant e Gateway, es: storno, riaccredito, ecc.).

Nel frattempo spero che questo Tutorial sia risultato chiaro e utile.
Buon lavoro!

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…

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)