spadamar, Autore a Mario Spada

P4A framework: come stampare un pdf

27 Maggio 201310 Novembre 2007 di spadamar

Nella documentazione del framework PHP P4A della Crealabs, non ci sono informazioni troppo dettagliate su come
produrre report in formato pdf. Cercando nei thread del forum, ci sono diversi frammenti ed indizi, che
aiutano parecchio, ma si perde un po’ di tempo a metterli insieme per produrre il codice necessario a
generare il report come si desidera. In questo articolo mostrerò la soluzione che ho scelto mettendo insieme i vari indizi, e applicandola alla base application “Products Catalogue” distribuita sul sito della Crealabs come applicazione di esempio.

Step 1: scelta ed installazione delle librerie pdf

In questo thread del forum, viene suggerito di usare le librerie FPDF o R&OS.
Ho scelto R&OS semplicemente perché in passato avevo avuto qualche difficoltà con FPDF, probabilmente per mia colpa. Credo che siano in sostanza equvalenti.
Una volta scaricato il pacchetto, è necessario creare nella root della applicazione (nel nostro caso: localhost/p4a/applications/products_catalogue/) una cartella che si deve chiamare
libraries. All’interno di questa cartella vengono decompresse le librerie (nel nostro caso i due files: class.pdf.php e class.ezpdf.php) e la cartella fonts contenente i file per la generazione dei font.

Step 2: Aggiunta di un pulsante nella toolbar

A questo punto bisogna creare un pulsante per la generazione del report in pdf. Personalmente ho scelto di crearlo nella toolbar, ma evidentemente si può crearlo dove si vuole.
All’interno del file products.php sarà sufficiente aggiungere questo codice PHP:

// Toolbar
$toolbar = &amp; $this->build("p4a_standard_toolbar",
                              "toolbar");
$toolbar->setMask($this);
$toolbar->addSeparator($position = "left");
// Aggiungo un pulsante alla toolbar per la stampa su pdf
$toolbar->addButton('stampapdf','pdf');
// Intercetto onClick per eseguire stampa_documento()
$this->intercept($toolbar->buttons->stampapdf,
                 'onClick','stampa_documento');

Notate che, per comodità, ho creato una variabile $toolbar contenente l’oggetto toolbar.
Il secondo parametro 'pdf' passato al metodo addButton crea automaticamente un img link all’icona pdf.png.
Questa icona deve essere presente nella cartella di default per il set di icone di P4A: localhost/p4a/icons/default/32/

In alternativa, si può impostare a NULL questo parametro per lasciare solo la scritta impostata ('stampapdf').

L’ultima riga di codice intercetta l’evento onClick sul pulsante ed esegue il metodo stampa_documento

Step 3: Aggiunta del metodo stampa_documento

function stampa_documento()  
// funzione per la stampa su pdf
  {
  require('class.ezpdf.php');
  $pdf =&amp; new Cezpdf('a4','portrait');
  $pdf->selectFont($_SERVER['DOCUMENT_ROOT'].
                   P4A_APPLICATION_PATH.
                   '/libraries/fonts/Helvetica');
  $db =&amp; p4a_db::singleton();
  $res = $db->getAll("SELECT model,
   brands.description AS brand,
   categories.description AS category, selling_price
   FROM products
   LEFT JOIN brands
   ON brands.brand_id = products.brand_id
   LEFT JOIN categories
   ON categories.category_id = products.category_id");
  $pdf->ezTable($res,'','Products',array('fontSize'=>12));
  $type = 'application/pdf';
  $filename = 'report.pdf';
  header("Pragma: public");
  header("Cache-Control: must-revalidate, post-check=0,
         pre-check=0");
  header("Cache-Control: private", false);
  header("Content-type: $type");
  header("Content-Disposition: attachment;
          filename=\"$filename\"");
  $pdfcode = $pdf->output(1); // flusso dati senza header
  header("Content-Length: " . strlen($pdfcode));
  echo $pdfcode;
  die();
  }

Note: nella variabile $res viene memorizzato un’array multidimensionale associativo che è il risultato della query. Come esempio ho preparato una query di tipo JOIN perché nella maggior parte dei casi, è proprio questo il tipo utilizzato.

Il path per la scelta dei font deve essere assoluto, per averlo in termini relativi è possibile utilizzare la variabile $_SERVER['DOCUMENT_ROOT'] propria del PHP e la costatnte P4A_APPLICATION_PATH propria del framework P4A.

Per forzare il browser ad aprire il report pdf in una nuova finestra, ho cambiato l’header del documento generato, specificando che il contenuto è un attachment. Altrimenti, il contenuto viene riconosciuto come mime-type 'application/pdf' e (a seconda dei browser utilizzati) viene aperto nella stessa finestra.

Infine il nuovo processo viene terminato attraverso l’istruzione die();

Download:

Il sorgente comprende anche le librerie R&OS e l’SQL per creare il database con alcuni record d’esempio per il report in pdf. Il report generato è visualizzabile qui.

Conclusioni:

Il framework P4A è uno strumento davvero ben fatto, gli autori hanno fatto un gran lavoro, adesso sta a noi utilizzatori, attraverso l’interscambio di informazioni, generare la documentazione necessaria al suo sviluppo.
A tal proposito è mia intenzione produrre altra documentazione su altri aspetti di comune interesse agli utilizzatori di questo ottimo framework.

Riferimenti ed approfondimenti:

Valerio Maglietta ha scritto:

Definire ottima questa imbeccata di Mario Spada e’ il minimo…
L’unica aggiunta che mi sento di consigliare è quello di preprocessare il contenuto della stringa da stampare tramite iconv.
Ovvero per noi Italiani:

$res = iconv(‘UTF-8’, ‘CP1252’, $res);

prima dare in pasto $res a ezTable come nell’esempio precedente

In questa maniera caratteri accentati, simbolo euro e simili, non ci daranno problemi.
Nel mio caso (so linux Ubuntu 7.10) la codifica iniziale è UTF-8 ma potrebbe essere differente (ISO-8859-1, ISO-8859-16).
CP1252 è la codifica Windows Western European (sembra che R&OS sia stato sviluppato proprio sotto win…).

Grazie 1k Mario!

Un framework PHP facile, moderno e italiano: P4A

27 Maggio 20134 Novembre 2007 di spadamar

L’utilizzo di un framework fornisce ai programmatori PHP che hanno scelto le applicazioni web come via di sviluppo, un comodo strumento per la costruzione delle maschere, le connessioni ai database, l’implementazione di menù e pulsantiere e tutti gli altri aspetti dell’applicazione che sono accessori indispensabili di qualsiasi programma. In questo modo lo sviluppatore si può concentrare maggiormente sulla logica dell’applicazione, lasciando al framework e ai suoi widget il compito della presentazione e della interazione con i dati.
Per chi ha scelto come linguaggio di sviluppo il PHP, non c’è che l’imbarazzo della scelta. Ma quali sono i criteri per fare una scelta corretta?

Secondo la mia opinione, principalmente due: il tipo di prodotto che si deve realizzare e il tempo di apprendimento per padroneggiare il framework. Altri criteri importanti sono la documentazione e la portabilità. Infatti se il framework richiede, per la propria installazione, requisiti difficilmente presenti sulla maggior parte dei provider, sarà poi difficile mettere in piedi un prodotto competitivo. Avendo l’esigenza di sviluppare un’applicazione per la gestione della produzione di una piccola impresa, la nostra scelta è caduta su un framework tutto italiano sviluppato da Andrea Giardina e Fabrizio Balliano della Crealabs denominato: P4A (PHP for Applications).

Quali sono i principali vantaggi di P4A?

Semplicità dell’installazione e portabilità
Apprendimento molto rapido
Persistenza dello stato durante l’esecuzione dell’applicazione
Presenza di utili widget per menù, navigazione del database, creazione di form e tabelle
Presenza di un buon numero di applicazioni base ed esempi
Semplicità del codice sorgente
Struttura moderna, orientata agli oggetti
l’HTML generato presenta un buon grado di accessibilità
Supporto ajax
Possibilità di interagire con gli autori in lingua italiana (chi fa questo mestiere dovrebbe conoscere bene l’inglese… ma esprimersi in madre lingua è sempre un’altra cosa!)

E quali, invece, gli svantaggi?

Manuali inesistenti
Documentazione delle classi completa ma poco dettagliata
Inadatto ai siti web veri e propri (gli autori stessi dichiarano che il framework è stato progettato per applicazioni web di tipo gestionale)
Impossibilità di avere il completo controllo del codice, ma questa è una caratteristica comune a tutti i framework, anzi quelli più complessi sono anche molto più criptici

Conclusioni:

Il framework P4A rappresenta un ottimo strumento per la realizzazione di applicazioni web, anche complesse, soprattutto di tipo gestionale. La semplicità di installazione ed utilizzo ripagano ampiamente la minore dotazione e flessibilità rispetto ai blasonati Zend Framework, Symphony e CakePhp. Seppure la dotazione manualistica è inesistente, l’ampio numero di esempi disponibili in rete e la presenza di un forum abbastanza attivo supplisce a questa mancanza. Infine l’attività di manutenzione e sviluppo da parte degli autori insieme al fatto che il prodotto ha ottenuto il ragguardevole numero di 130.000 download è garanzia di vitalità e supporto anche nel futuro.

Riferimenti ed approfondimenti:

Burocrazia e tasse provano ad attaccare il mondo libero di Internet in Italia

3 Giugno 201121 Ottobre 2007 di spadamar

Ha suscitato un putiferio la notizia pubblicata da Punto Informatico, sull’approvazione da parte del Consiglio dei ministri di un disegno di legge che obbligherebbe qualsiasi ente o persona che scrive su un blog o comunque pubblica su un sito Internet, ad essere registrato presso il R.O.C..

Punto Informatico, la più autorevole e storica testata giornalistica on-line specializzata in temi che riguardano Internet e le tecnologie informatiche, ha rilanciato una notizia apparsa su un editoriale di Civile.it sito che si occupa di documentazione giuridica.

Non se ne era accorto nessuno! Questo è l’incredibile…

Poche ore dopo la pubblicazione della notizia si è scatenato sulla rete, un coro di sacrosante proteste dai più accaniti paladini della libertà di espressione, fra cui si impone di citare, immancabile: Beppe Grillo.

A questo punto due autorevoli membri del governo (Gentiloni e Di Pietro ndr), forse perché loro stessi scrivono nei propri blog, si sono accorti delle vessazioni proposte dai loro colleghi e hanno fatto ammenda assicurando che il disegno di legge sarà al più presto rivisto e che sarà garantita la libertà di scrivere su un blog. senza ulteriori tasse e carte bollate a chiunque voglia farlo.

Ok si fa marcia indietro (speriamo…), ma ci volevano Punto Informatico e Civile.it per far notare la gaffe di questo disegno di legge?
Non se ne potevano accorgere prima il Ministro delle Infrastrutture e il Ministro delle Comunicazioni?

Riferimenti ed approfondimenti:

Migrare da PHP4 a PHP5: differenze nel riferimento ad un oggetto

27 Maggio 201314 Ottobre 2007 di spadamar

Il 13 luglio 2007 il team di sviluppo del PHP ha annunciato la fine del supporto al PHP4 a partire dalla fine di quest’anno. Verranno ancora sviluppate eventuali patch di sicurezza solo fino ad agosto 2008. Fino ad oggi,

la maggior parte dei Internet Service Provider fornisce installazioni con PHP4, ma il recente annuncio del team di PHP forzerà gli Internet Service Provider all’aggiornamento verso il PHP5.

Questo non è affatto un passaggio negativo, né doloroso, infatti il PHP5 è ormai ampiamente rodato e non soffre di alcuni difettucci della versione precedente.

Inoltre è un linguaggio molto più moderno ed offre un supporto alla programmazione ad oggetti al pari di altri che hanno questa caratteristica fin dalla nascita come, per esempio, Java.

Insomma, questo passaggio dovrebbe essere davvero indispensabile, al punto che è persino nato un gruppo di famosi programmatori PHP (gophp5.org), quasi tutti del mondo Open source, che spinge a farlo.

Dicevo che il passaggio è anche indolore, infatti la retrocompatibilità è decisamente buona, sono solo poche le cose che devono essere modificate o al più possono provocare dei messaggi di tipo E_STRICT invece che E_NOTICE.

Il sito ufficiale pubblica un documento in lingua inglese con le indicazioni per la migrazione, PHPNews.it inoltre, ha pubblicato in lingua italiana un documento ancora più dettagliato concernente tutti i possibili problemi di migrazione.

Un nuovo importante aspetto del PHP5 è sicuramente la correzione della gestione dei riferimenti agli oggetti nel motore dell’interprete Zend.
Osserviamo, ad esempio, come si comporta PHP4 con questo frammento di codice:

class PersonaggiFortunati {
    var $nome;
    function PersonaggiFortunati() {
        $this->nome = "Topolino";
    }
 
}
 
$personaggi_fortunati = new PersonaggiFortunati;
 
echo $personaggi_fortunati->nome;
 
print("<br />");
 
$personaggi_sfigati = $personaggi_fortunati;
 
$personaggi_sfigati->nome = "Paperino";
 
echo $personaggi_fortunati->nome;
 
print("<br />");

Osservando il risultato in PHP4:

Topolino
Topolino

… Paperino non diventa fortunato… mentre in PHP5:

Topolino
Paperino

Questo avviene perché, mentre in PHP4 l’assegnazione di un oggetto ad una variabile avviene per valore, in PHP5 avviene implicitamente per riferimento.

Per ottenere lo stesso risultato in PHP4 avremmo dovuto cambiare il codice:

$personaggi_sfigati = $personaggi_fortunati;

in:

$personaggi_sfigati = &amp; $personaggi_fortunati;

Cioè, avremmo dovuto esplicitamente indicare che stiamo assegnando un oggetto per riferimento, attraverso l’operatore &. Questa procedura è consigliata sempre in PHP4 perché evita il sovraccarico della memoria che avviene con la duplicazione degli oggetti.

Se volessimo comunque mantenere il comportamento di PHP4 in PHP5, e risolvere i nostri problemi di compatibilità senza pensare troppo alla gestione della memoria, sarà sufficiente cambiare questa riga di codice:

$personaggi_sfigati = $personaggi_fortunati;

in:

$personaggi_sfigati = clone $personaggi_fortunati;

Conclusioni:

A discapito di poche differenze, è senz’altro consigliabile la migrazione al PHP5 che rappresenta un’evoluzione notevole del linguaggio. E’ auspicabile che chi ha utilizzato PHP fino ad oggi utilizzando una logica procedurale, approfitti dell’occasione per una definitiva conversione alla programmazione per oggetti.

Riferimenti ed approfondimenti:

Come evolve il web: l’X/HTML 5

3 Giugno 20116 Ottobre 2007 di spadamar

Nel futuro del web si profila una svolta simile a quella del 1999-2002.
All’epoca l’introduzione dell’XHTML 1.0 che applica le rigide regole dell’XML all’HTML 4.01, metteva a freno il dilagare di documenti web
compilati in maniera maldestra per non dire completamente errata. Il parsing dei documenti da parte del browser (allora non c’era molta scelta…) presentava comunque un documento leggibile,
perché la gestione degli errori da parte del browser era molto tollerante. L’evoluzione di internet e quindi l’utilizzo di differenti user agent che avevano comportamenti differenti nell’interpretazione delle pagine malformate, ha fatto si che si ponesse un freno tutto ciò. Oltre alla richiesta di correttezza formale dei documenti web, bisogna tenere in considerazione anche la spinta dovuta ad una maggiore sensibilità verso l’accessibilità che è fra i principi promotori dell’XHTML 1.0, l’introduzione del web semantico e degli altri aspetti del cosidetto Web 2.0 e l’esigenza di una migliore indicizzazione sui motori di ricerca (i crawler preferiscono documenti corretti).

Molti addetti ai lavori, particolamente gli sviluppatori web piuttosto che i grafici “fac-totum” del web, hanno aderito al progetto, sebbene ancora oggi a quasi 8 anni dalla nascita di XHTML si stima che il 95% delle pagine web non siano valide! Il problema è che finché i browser faranno il parsing di un documento come fosse una zuppa di tag (tag soup), gli autori dei minestroni saranno sempre tranquilli che gli utenti continueranno a cibarsene. Infatti, un documento ben formato e un minestrone di tag serviti al browser con un content-type di tipo “text-html” risulteranno agli occhi dell’utente, identici. D’altra parte, a tutt’oggi solo i browser più recenti sono in grado di effettuare il parsing di un documento XHTML servito come dovrebbe, cioè come “application/xhtml+xml”. Ad ogni modo chi ha scelto l’XHTML strict si è almeno messo sulla buona strada per non dover rifare tutto in futuro (oltre a stare in pace con la propria coscienza di professionista del web).

Cosa è e cosa si propone di fare l’X/HTML 5?

La definizione, dalle parole di Ian Hickson

“E’ una nuova versione di HTML che ambisce a rimpiazzare HTML4 e XHTML1”

per ora in fase di bozza lo sviluppo viene curato da WHATWG

in maniera totalmente aperto, chiunque può partecipare. Uno degli aspetti più interessanti di questo progetto è senza dubbio l’idea che si possa finalmente avere un comportamento omogeneo dei browser, in virtù del fatto che i maggiori produttori (Mozilla, Apple, Opera software) sono già coinvolti e sembra che anche la Microsoft sia interessata all’iniziativa. Se poi questi produttori ne terranno conto davvero o meno, questa è un’altra storia.

Vediamo ora alcune novità:

Ampio supporto alle applicazioni web
Correzione degli errori dell’HTML4
Semplificazione del web rispetto al futuro XHTML2
Fusione dei modelli di Web applications 1.0, Web forms 2.0, Web controls 1.0 proposti da Mozilla, Apple ed Opera software
Nuova e razionale gestione della struttura del documento mediante nuovi tag: article, nav, header, footer. Sezioni logiche del documento divise in: contenuto, menù di navigazione, intestazione, piede di pagina. Vantaggi per i browser per palmari che potranno visualizzare solo la sezione che interessa
Limitazione all’utilizzo di javascript per il controllo dei forms, che sarà integrato nell’HTML
Introduzione dell’elemento canvas per la costruzione di immagini bitmap (tipo Yahoo pipes)
Specifico supporto per applicazioni web tipo Google Gear: implementazione di un sistema di salvataggio dati sul proprio sistema, editing negli elementi dei documenti, supporto al drag’n’drop
Introduzione di tag video e audio
Introduzione dell’elemento progress (barra di avanzamento), datagrid (griglia per tabelle)
Introduzione all’elemento dialog (supporto a chat)

Conclusioni:

l’X/HTML5 sarà molto probabilmente il futuro del web, gli sviluppatori troveranno uno strumento molto più potente di quelli che hanno avuto in passato, verranno corretti molti errori di forma e di sostanza sull’impronta della qualità dell’applicazione. l’XHTML2 d’altra parte ha troppi problemi di retrocompatibilità con i vecchi browser perché ha intrapreso una strada troppo rigida, peraltro inevitabile, per abbracciare in pieno la logica XML.
Ma l’X/HTML 5 rimarrà sostanzialmente un linguaggio markup strettamente legato ai browser, se un programmatore si vuole evolvere davvero, dovrebbe orientarsi verso piattaforme più ad alto livello, quali quelle che integrano XML, UML e paradigmi orientati agli oggetti

Riferimenti ed approfondimenti:

Applicazioni Web contro applicazioni desktop

3 Giugno 201118 Settembre 2007 di spadamar

Prendo spunto da un interessante articolo apparso su Usabile.it per stigmatizzare alcuni importanti vantaggi delle applicazioni web rispetto a quelle desktop. Senza dubbio, l’avvento del Web 2.0 e soprattutto le nuove tecnologie che sono nate contestualmente, AJAX in primis, hanno contribuito enormemente all’espansione delle applicazioni web.
G-mail è l’esempio più tangibile. Sono dell’idea che, a parte i vantaggi che AJAX puň offrire in termini di funzionalità aggiuntive all’austera interfaccia HTML, sono molto più appetibili le caratteristiche intrinseche di un’applicazione che non necessita di una installazione client per client e, come viene sottolineato dall’articolo di Boscarol, l’approccio perpetual beta che permette un continuo affinamento dell’applicazione, in maniera molto poco intrusiva (forse anche troppo…).
Le applicazioni che esentano lo sviluppatore dal tedioso compito di fornire pacchetti autoinstallanti esenti da bugs e soprattutto intelligenti al punto di prevenire gli errori dovuti a differenti sistemi operativi o versioni di sistema operativo, di differenze nelle service pack installate, configurazioni errate e non ultimo, la presenza di virus, sono una gran bella cosa! Chi ha sviluppato per anni in Visual Basic o Delphi lo sa bene, anche gli sviluppatori JAVA hanno avuto i loro bravi guai con le differenti versioni di JVM.
Le applicazioni web, invece, necessitano solo di una installazione server, nel più dei casi gestibile da remoto, un buon RDBMS che funzionerà sicuramente meglio su di un server vero, presumibilmente in hosting, quindi con pochi problemi di gestione della sicurezza, di reliability e fault-tolerance, normalmente a carico del provider.
Certo esiste anche il rovescio della medaglia, ad esempio il maggior tempo necessario a sviluppare l’applicazione rispetto all’uso di ambienti RAD o la difficoltŕ maggiore nel gestire le stampe. Difficoltà che si vanno assottigliando con la sempre maggior diffusione di ambienti di sviluppo framework per gli script web server-side.
Non dimentichiamo, infine, il monito di Tim O’Reilly e Bill Higgins che, nel loro articolo “The Uncanny Valley of User Interface Design” lanciano un appello agli sviluppatori di applicazioni web per rimanere concentrati sul fatto che un’applicazione web deve essere “accordata” al suo ambiente. In sintesi, O’Reilly e Bill Higgins dicono che non bisogna lasciarsi prendere troppo la mano dal fatto che le nuove tecnologie permettono di trasformare uno strumento che ha il DNA per vivere nel web, in un animale dall’aspetto “desktop”. (La Uncanny Valley è un concetto della robotica che dice che esiste un punto nel quale il reiterato aumento di imitazione del comportamento umano da parte dei robot, li rende infine, meno simili agli umani).