PHP

fonte: dal web

Piccoli trucchi per chi non ha a disposizione un vero debugger come XDebug o Zend Debugger. In mancanza di un debugger degno di questo nome può essere difficoltoso, soprattutto in contesto PHP, trovare un bug o analizzare i dati contenuti nel flusso di elaborazione  per capire quale sia il problema o il motivo per cui si presenta un risultato che non ci aspettiamo.

In alcuni casi utilizzare la stampa a video dell’errore può non essere possibile o assolutamente da evitare, ad esempio nel caso in un contesto di produzione. In queste situazioni possiamo sfruttare un semplice sistema di logging, ovvero riportare in un file di testo gli errori generati dall’applicazione o altre informazioni importanti che chiaramente non vogliamo rendere pubbliche. Oltre alla stampa semplice dell’errore però, nella maggior parte dei casi, abbiamo anche bisogno di utilizzare le funzioni di ispezione come “var_dump” o “print_r” , che ci facilitano l’analisi. Il problema è che le informazioni restituite da queste funzioni sono strutturare in modo complesso, e dunque non è così immediata la stampa su file.

Per risolvere il problema possiamo utilizzare l’output buffering di PHP:

(continua…)



Zend Framework

fonte: dal web

Piccolo appunto da tenere sempre pronto per chi sviluppa con Zend Framework, il potente framework rilasciato dalla Zend Technologies. Zend Framework implementa i database Adapter per fornire un ulteriore livello di astrazione e facilitare così la connessione delle nostre applicazioni in PHP con diversi RDMBS.

L’implementazione vera e propria è data dalla classe Zend_Db_Adapter : esiste un Adapter per ogni RDMBS disponibile, e comunque il framework è predisposto per poter scrivere nuove implementazioni senza particolari problematiche. Nella pagina della documentazione relativa alla classe Zend_Db_Adapter è disponibile l’elenco degli Adapter che Zend_Db fornisce al driver PDO per accedere ai diversi RDMBS.

(continua…)



Zend Framework

fonte: dal web

Questo è uno dei trucchetti che può davvero far comodo conoscere quando sviluppiamo web application con Zend Framework (ZF). Quando creiamo un progetto con ZF ci troviamo di fronte una struttura tipicamente simile alla seguente:

nome_preogetto/
   application/
      controllers/
      models/
      views/
         scripts/
   library/
   public/
   tests/

(continua…)



sencha extjs

fonte: dal web

In questo articolo vedremo come gestire in un layout complesso un tree panel ExtJs con PHP. Il tree panel è un componente ExtJs che ci permette di gestire una categorizzazione di elementi attraverso l’utilizzo di un albero: l’albero è molto comodo per gestire grandi quatità di dati, perchè essendo una struttura gerarchica risulta chiara e semplice da utilizzare per l’utente finale.

Un “layout complesso” è un layout che combina insieme diverse strutture, in modo da creare delle interfacce più ricche di informazioni e che, interagendo tra loro, permettono di usufruire delle informazioni in maniera più chiara e diretta. Prima di iniziare ad analizzare il codice, cerchiamo di focalizzare quanto vogliamo ottenere. Il risultato finale di questo tutorial è disponibile al seguente indirizzo.

(continua…)



PHPExtJs (oggi Sencha) è uno dei principali framework javascript attualmente disponibili: è potente, flessibile, cross-platform, ed è probabilmente uno degli strumenti più veloci per realizzare rich internet applications. In questo articolo vedremo i concetti principali che permettono di integrare ExtJs in una web application PHP-based attraverso il protocollo JSON.

(continua…)



Zend FrameworkProseguiamo lo studio di Zend Framework analizzando le diverse tecniche possibili per accedere ai dati di configurazione contenuti nel file application.ini . L’ application.ini è il file responsabile della configurazione della web application: in questo file sono contenute informazioni sensibili, come ad esempio le credenziali della base di dati, i percorsi delle directory principali, e molto altro ancora. Il file ha una struttura gerarchica che permette di utilizzare contemporaneamente più configurazioni diverse (es. “produzione”, “testing”, “develop”).

(continua…)



Zend FrameworkIl messaggio di errore “Could not determine temp directory, please specify a cache_dir manually” viene restituito da Zend Framework quando non è impostata o non è possibile scrivere nella directory per il salvataggio dei dati temporanei. Questo provoca chiaramente l’immediato crash dell’applicativo.

(continua…)



Lavorando con Zend Framework in diverse occasioni avremo la necessità di disabilitare il layout e la renderizzazione della vista. Per effettuare l’upload di file ad esempio potrei aver bisogno di una action da richiamare in un determinato controller, senza però per forza applicare a questa una vista.
(continua…)



Qualche giorno fa ho iniziato il nostro percorso di conoscenza “avanzata” di Zend Framework raccontando in questo articolo come il framework gestisce le transazioni sui nostri database.

Con questo articolo proseguiamo la conoscenza di Zend Framework trattando un altro interessante argomento di vitale importanza per lo sviluppo di un’applicazione web “moderna” che possa interagire con il mondo esterno utilizzando le principali tecniche e i più diffusi protocolli di comunicazione. L’argomento che vediamo è la gestione dei contesti (context) in Zend Framework.

(continua…)



Zend Framework è uno tra i principali framework (se non il principale) per lo sviluppo di applicazioni enterprise in PHP. E’ uno strumento molto potente al servizio degli sviluppatori PHP: è estremamente flessibile, estendibile, facile da usare e decisamente manutenibile. Questo è il primo di una serie di articoli che sto preparando per presentare quelle che sono le caratteristiche più interessanti di questo prodotto.

L’argomento che trattiamo in questo articolo è la gestione delle transazioni con Zend Framework. Una transazione è una sequenza di operazioni che deve rispettare le proprietà ACID ( Atomicity, Consistency, Isolation, e DurabilityAtomicità, Coerenza, Isolamento e Durabilità). Una transazione può terminare con successo o con un insuccesso: nel primo caso il risultato sarà permamente, mentre nel caso di insuccesso di deve tornare alla situazione precedente l’inizio della transazione, come se nulla fosse successo.

(continua…)



Quando scriviamo il nostro codice è davvero comodo avere un assistente che ti suggerisce ad esempio i metodi che possiamo richiamare su un oggetto o le classi che abbiamo a disposizione per raggiungere il nostro obiettivo. Sono strumenti che quando inizi ad usare non puoi più farne a meno.

Il “Code Assistant” di Eclipse è uno strumento molto potente, che non solo suggerisce le librerie di default del linguaggio di programmazione con il quale stiamo lavorando (Java, PHP, ecc.) ma permette anche di personalizzare le librerie a disposizione, aggiungendone ad esempio di terze parti.

Questo non solo velocizza la scrittura del codice, ma permette anche di imparare molto più rapidamente il linguaggio o i framework che stiamo utilizzando nel nostro applicativo. Quando però lavoriamo in team su un progetto, è molto probabile che si utilizzino i plugin come quello di subversion per gestire il lavoro. Il problema è che quando lavoriamo in questo ambiente, di default, il progetto perde l’indicazione sulla sua stessa natura….in pratica Eclipse non sa più se stiamo lavorando in PHP o Java, sa solo che stiamo lavorando con subversion, perdendo in questo modo il prezioso aiuto che ci fornisce il Code Assistant. Ma per risolvere questo problema ci vogliono davvero 5 minuti…

Dobbiamo concentrare la nostra attenzione sui file “.buildpath” e “. project” del nostro progetto Eclipse: se li editiamo noteremo che non vi sono indicazioni circa la natura del progetto (cioè se siamo in ambiente Java, PHP o Javascript). Tutto ciò che dobbiamo fare è inserire nei rispettivi file le seguenti direttive in neretto:

.PROJECT

<?xml version=”1.0″ encoding=”UTF-8″?>
<projectDescription>
<name>prova</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.wst.validation.validationbuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.dltk.core.scriptbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.php.core.PHPNature</nature>
</natures>
</projectDescription>

.BUILDPATH

<?xml version=”1.0″ encoding=”UTF-8″?>
<buildpath>
<buildpathentry kind=”con” path=”org.eclipse.php.core.LANGUAGE”/>
<buildpathentry external=”true” kind=”lib” path=”/myLibrary”/>
<buildpathentry kind=”src” path=”"/>
</buildpath>

A questo punto, una volta riavviata l’IDE, il nostro progetto sarà etichettato in base alla sua natura, e dunque si riattiveranno tutte le funzionalità e tutti gli strumenti a disposizione per lo sviluppo con l’ambiente che abbiamo impostato (e il Code Assistant non fa eccezione! ;) )



Le chiamate asincrone sono ormai un fondamento delle interfacce web, e praticamente tutti i principali framework javascript in circolazione forniscono degli strumenti embedded che semplificano lo sviluppo e automatizzano la maggior parte delle impostazioni.

ExtJs è un framework javascript che è riuscito ad ottenere forti consensi nell’ambito dello sviluppo di interfacce web: questo grazie soprattutto alla potenza del prodotto e alla comunità decisamente attiva che fornisce un importante supporto agli sviluppatori.

Il meccanismo implementato da questo  framework per eseguire chiamate Ajax è estremamente semplice ed intuitivo, meccanismo che tra le altre cose ricorda molto da vicino quello adottato da altri framework javascript come JQuery. Vediamone un esempio:

Ext.Ajax.request({
[…]
url: ‘pagina.php’,
params: {id: ‘3’},
success: function(resp) {
[…]
} ,
failure: function(a, b) {
[…]
}
});

Con queste poche righe di codice, ExtJs ci permette di eseguire una chiamata Ajax verso l’indirizzo specificato nel parametro di configurazione “url” (pagina.php) e di gestire sia il caso di risposta positiva sia il caso di insuccesso.
“params” invece permette di specificare i parametri che verranno inviati al file “pagina.php” durante la chiamata Ajax: nel nostro esempio inviamo un parametro con identificativo “id” che contiene il valore 3.

E se volessimo inviare un array? Nessun problema, ci viene in aiuto JSON.

ExtJs è chiaramente progettato per fornire pieno supporto a JSON, dunque possiamo sfruttare questo protocollo. Codifichiamo quindi il nostro array utilizzando le funzioni che ExtJs ci mette a disposizione, come ad esempio la seguente:

Ext.encode(array)

Supponendo quindi di voler inviare un array di valori con una chiamata Ajax il nostro codice potrebbe diventare:
Ext.Ajax.request({
[…]
url: ‘pagina.php’,
params: {data: Ext.encode(arrayData)},
success: function(resp) {
[…]
} ,
failure: function(a, b) {
[…]
}
});

Lato server, sarà sufficiente eseguire il decoding del parametro “data”, che giunge al server sottoforma di stringa JSON:

$myArray = json_decode($_POST[‘data’]);



Eclipse è un IDE meravigioso: con un’architettura modulare ( a plugin ), con gli strumenti di debug e con una stabilità che suscita invidia….il tutto open source!!

Vi sono varie versione pre-configurate di Eclipse, in base alle esigenze dello sviluppatore: c’è la versione per gli sviluppatori J2EE, per applicazioni Java Mobile, per sviluppatori PHP, ecc.

Ma è anche possibile scaricarsi la versione base e scegliere “a mano” la configurazione che si preferisce, installando i plugin che necessitano allo sviluppatore.

Anche se Eclipse nasce principalmente per gli sviluppatori Java, negli ultimi anni sono state perfezionate versioni per i principali linguaggi web-side, come ad esempio PHP e Ruby. In questo articolo andremo a vedere come integrare il manuale PHP all’interno dell’IDE, in modo da avere a portata di click le principali librererie che questo linguaggio di programmazione mette a disposizione.

Di default, il PDT (PHP Development Tools ) di Eclipse segue il manuale online del famoso sito www.php.net: ovviamente questa è la scelta più comoda, visto che è sicuramente la documentazione più aggiornata di questo linguaggio. Il problema è che questa soluzione vale per un pc sempre connesso a Internet. Se abbiamo la necessità di lavorare sempre con la documentazione, anche quando non siamo connessi (e sarebbe un bene che tutti gli sviluppatori lo facessero), allora dobbiamo seguire questi semplici passi:

1) dal sito di riferimento www.php.net scarichiamo la versione html del manuale, situata al seguente indirizzo www.php.net/download-docs.php (nel caso il download sia congestionato, si può scaricare la documentazione anche dal mirror italiano, al seguente indirizzo)

2) Una volta scaricato e unzippato l’archivio, apriamo Eclipse (con il PDT già installato), andiamo su:

Window –> Preferences –> PHP —> PHP Manual

e creiamo un nuovo elemento cliccando sul tasto “New” e selezionando l’inserimento da cartella.

3) Ad inserimento effettuato, clicchiamo sul nuovo elemento e poi sul tasto “Default” se vogliamo che questa sia la versione di default del nostro manuale

A questo punto abbiamo finito: avremo a disposizione per il nostro sviluppo PHP il manuale e la documentazione vitale per ogni sviluppatore, sia che siamo connessi a Internet sia nel caso in cui ci troviamo a lavorare in assenza di connessione.



Quando si lavora con il framework EzPublish, bisogna tenere presente che questo utilizza pesantemente un sistema di caching assai potente quanto fastidioso in fase di sviluppo. L’importanza di questo sistema di caching è tale per cui ci sono degli aspetti che non possono essere tralasciati quando si lavora con questo prodotto.

Supponiamo ad esempio di dover spostare un servizio implementato con questo framework da un dominio in un altro; questo comporta l’obbligo di modificare almeno i seguenti dati:

- le variabili SiteURL contenute nei file di configurazione site.ini.append.php delle cartelle setting/siteaccess/<nome_siteaccess> e setting/override/<nome_siteaccess>

- i dati di accesso alla base di dati, sempre nei medesimi file

- ed infine è necessario svuotare tutte le cache, per azzerare i percorsi e alcuni dati precedentemente memorizzati in cache, appunto

Il problema è che spesso non si può utilizzare il sistema più semplice, ovvero quello di accedere nel pannello di amministrazione e servirsi della sezione dedicata per la gestione della cache. Per questo motivo, vi indichiamo brevemente tutti i metodi che possiamo utilizzare per compiere l’azione di svuotare tutte le cache.

1) Dal pannello di Amministrazione

Utilizziamo il pannello di amministrazione per pulire tutte le cache via GUI:

  1. Entrare nel tab “SETUP”
  2. Cliccare sull’icona di cancellazione di tutte le cache
  3. Aggiornare il browser

2) Dalla Linea di commando

Questo è un processo che spesso passa inosservato, ma che è molto comodo in situazioni come quella di cui sopra, ovvero quando si sposta un’installazione di EzPublish. In sistemi a base Unix, è sufficiente utilizzare i seguenti comandi:

cd /percorso/di/ezpublish;
./bin/php/ezcache.php --clear-all --purge;

Se invece si utilizza un sistema Windows, i comandi da utilizzare sono i seguenti

# cd c:/web/pro/ezpublish/doc;/bin/php/ezcache.php --clear-all --purge;
c:\php\php .

3) Procedimento manuale

E’ anche possibile pulire le cache a mano, nel caso in cui non sia possibile utilizzare uno dei metodi precedenti. Per fare questo, è sufficiente seguire questa procedura (per sistemi Unix – per sistemi Windows è sufficiente cancellare le medesime cartelle):

cd /percorso/di/ezpublish;
rm -vrf /var/cache;
rm -vrf /var/<tipo di installazione(ezwebin_site, ezflow_site,ecc)>/cache


Quando si utilizza il settaggio di default di EzPublish, l’inoltro delle mail (ad esempio quelle per gestire la modifica della password) potrebbe non funzionare correttamente. La ragione è semplice: qmail, per funzionare regolarmente, necessita di configurazioni mail differenti da quelle che EzPublish ha per default.

Per permettere il corretto inoltro delle mail, dobbiamo settare alcuni parametri di configurazione del file

settings/override/site.ini.append.php

Nel caso in cui si utilizzi il protocollo SMTP per l’invio della posta, è necessario utilizzare una configurazione molto simile alla seguente:

[MailSettings]
Transport=SMTP
AdminEmail=tuamail@mail.com
EmailSender=tuamail@mail.com
#Beware about white space at end of each line
TransportServer=localhost
HeaderLineEnding=%0D%0A
TransportPort=25
TransportUser=
TransportPassword=

Nel caso invece si utilizzi sendmail, la configurazione deve essere simile alla seguente:

[MailSettings]
Transport=sendmail
AdminEmail=tuamail@tuamail.com
EmailSender=tuamail@tuamail.com
#Beware about white space at end of each line
HeaderLineEnding=auto
Dopo queste modifiche è necessario svuotare la cache delle impostazioni INI. Se l'invio delle mail
non dovesse ancora funzionare, allora potremmo essere di fronte a uno dei seguenti casi:
  1. Problema: Le mail arrivano con una Header scorretta utilizzando sendmail
    Soluzione: E’ nececssario cambiare il valore della direttiva HeaderLineEnding in “auto”
  2. Problema: Utilizzando il protocollo SMTP le mail non arrivano a destinazione
  3. Soluzione Qualche impostazione potrebbe non essere corretta. Ricontrollare il blocco di codice relativo
  4. Problema: La mail non arrivano quando la piattaforma EzPublish e il server mail girano su macchine diversa.
    Soluzione:L’inoltro locale delle mail potrebbe essere ancora attivo. Disabilitarlo dal proprio pannello di hosting ( nel caso di Plesk: Domain->Mail->Disable/Enable Switch )
  5. Problema: Il protocollo SMTP non funziona con EzPublish 4.0.0
    Soluzione: Questo è un bug. Eseguiamo l’upgrade a EzPublish 4.0.1 o eseguiamo il path del file ezsmtp.php
  6. Problema: Le configurazione di cui sopra non funzionano
    Soluzione: Ci potrebbe essere uno spazio bianco alla fine del codice. Rimuovetelo.