Eseguire chiamate AJAX con jQuery e JSON in WordPress

Ajax and WordPress

Succede sempre più di frequente di dover effettuare delle chiamate ajax in WordPress. In questo articolo vedremo come effettuare delle chiamate asincrone senza dover creare nuove pagine WordPress ma sfruttando lo script utilizzato dall’interfaccia del wp-admin.
Nell’esempio in questione, la chiamata AJAX restituirà un file JSON formato davvero utile per rappresentare i dati restituiti da una query. Lato javascript useremo la funzione $.getJSON(…) di jQuery mentre lato server scriveremo il nostro script all’interno del file functions.php presente in qualsiasi tema WordPress.

Per prima cosa dobbiamo creare la corrispondenza tra una nuova action e la nostra funzione php:

add_action('wp_ajax_myaction', 'my_function');

Fatto ciò possiamo scrivere la nostra funzione my_function la quale corrisponderà all’azione myaction (il nome è puramente indicativo, potete chiamare l’azione e la funzione come preferite):

function my_function() {
  global $wpdb;
  $id = $_GET['id'];
  $rows = array();
  $q = "SELECT * FROM my_table WHERE id = ".$id;
  $rows['results'] = $wpdb->get_results($q, ARRAY_A);
  if(count($rows) <= 0){
    return false;
  }
  echo json_encode($rows);
  exit();
}

In questo script trovate tutto l’indispensabile per completare la parte lato server. Come si può intuire la query dovrà utilizzare un parametro passato in GET, poi utilizzando la variabile globale wpdb effettueremo la query sul database. La json_encode trasformerà l’array associativo con i record letti tramite la SELECT in una stringa JSON e la stamperemo a video tramite l’echo. Non dimenticate la exit() finale perchè altrimenti verrà stampato uno “0” che vi metterà in difficoltà nel parsificare il JSON.

Un ultimo particolare di cui tenere conto è che la add_action crea un’azione per l’admin-ajax.php che è un file accessibile solo da utenti loggati, quindi per consentire l’esecuzione dell’azione sia da utenti registrati sia da ospiti sarà necessario aggiungere un’ulteriore linea di codice come questa:

add_action('wp_ajax_nopriv_myaction', 'my_function');

Dopo aver completato lo script PHP possiamo passare al lato client, con il codice javascript per la chiamata della funzione:

$jQ.getJSON('<?php echo get_bloginfo('url'); ?>/wp-admin/admin-ajax.php',{action: 'myaction',id: 'tuo_id'}, function(json){...Codice javascript per parsificare il json...}

Ho omesso l’inclusione di jquery in WordPress, ma potete trovare come fare in un mio precedente articolo che trattava l’argomento nello specifico.

A questo punto non vi resta che sbizzarrirvi con le chiamate ajax nel vostro template oppure dai vostri plugin (in quest’ultimo caso basta spostare il codice PHP in un file del vostro plugin).

Piccoli traguardi… piccole soddisfazioni, 2000 visite mensili!

Report Google Analytics

Cari lettori del blog, oggi ho raggiunto un piccolo ma importante traguardo… I dati di google analytics parlano chiaro, sono state sorpassate le 2000 visite mensili e per questo voglio condividere con voi alcune statistiche di cui vado fiero.

Dal 27 agosto al 26 settembre questo blog ha ricevuto 2004 visite, con 1672 visitatori unici e 2369 visualizzazioni di pagina di cui 2175 uniche. L’80,84% delle visite sono nuove e ovviamente il paese predominante è l’italia con 1910 visite  delle quali 1853 in lingua italiana.

I tre articoli più popolari per il momento sono nell’ordine “Creare un web service con soap e php” con 401 visualizzazioni, “Sincronizzare Google Calendar con iCal su Mac e iPhone” con 395 visualizzazioni e “Calibrare la batteria di un Macbook Pro e non solo…” con 323 visualizzazioni.

Grazie a tutti voi che mi leggete, continuate a farlo! Mi auguro di poter continuare a scrivere articoli (spero) interessanti per accrescere questi numeri!

A presto, Davide.

Eseguire un’applicazione Django su ubuntu server con nginx, gunicorn, upstart e mysql (DUNG stack)

Gunicorn

Oggi torno a scrivere sul blog per raccontare come eseguire il deploy di un’applicazione Django su ubuntu server con Nginx come web server, Gunicorn come application server WSGI e MySQL come DBMS.

Inizialmente per ospitare un’applicazione scritta con il framework Django utilizzavo un classico stack in stile LAMPP (Linux + Apache + mod_wsgi). Successivamente per cercare di limitare l’utilizzo di ram ho scoperto (grazie al blog degli ingegneri di instagram) lo stack DUNG che rappresenta la configurazione con nginx + gunicorn + ubuntu.

Non appena si iniziano le configurazioni si comprendono la semplicità e la velocità di messa a punto del nuovo stack. Nginx usa file di configurazione scritti con una sintassi simile ad un linguaggio di programmazione, molto più semplici da comprendere e da scrivere per chi ha poca dimestichezza con queste cose.

Per prima cosa installiamo nell’ordine mysql e nginx, successivamente installiamo django.

Fatto ciò, tramite easy_install possiamo installare Gunicorn:

sudo easy_install gunicorn

A questo punto dobbiamo configurare nginx come proxy server per le richieste: tutto ciò che riguarda i file statici (immagini, css, js, ecc…) verrà servito direttamente da nginx mentre le richieste inerenti il codice python dovranno essere girate al server WSGI (gunicorn nel nostro caso) che le eseguirà e restituirà la pagina risultante.

Come per apache i file di configurazione dei vari siti sono in /etc/nginx/sites-available (invece di /etc/apache/sites-available), per cui creiamo il file di configurazione per la nostra applicazione django in questo modo:

upstream project {
        server 127.0.0.1:8200 fail_timeout=0;
        server 127.0.0.1:8201 fail_timeout=0;
}

server {
        listen 80;
        server_name mydomain.com www.mydomain.com;
        access_log /var/log/nginx/mydomain_access.log;
        error_log /var/log/nginx/mydomain_error.log;

        root /srv/django_srv/mydomain/app;

        location / {
                proxy_set_header Host $host;
                if (!-f $request_filename){
                        proxy_pass http://project;
                        break;
                }

        }
        location /upload  {
                alias /srv/django_srv/mydomain/uploads;
                }
        location /static  {
                alias /srv/django_srv/mydomain/app/_statics;
        }
        location /admin/media {
                alias /opt/Django-1.3.1/django/contrib/admin/media;
        }
}

Come potete vedere nel blocco di configurazione upstream project a questo punto dobbiamo configurare gunicorn in modo da farlo rispondere sulla porta 8200 e 8201. In questo modo quando caricheremo aggiornamenti del nostro progetto e dovremmo riavviare gunicorn, il sito non sarà mai irraggiungibile, inoltre se il processo gunicorn dovesse crollare per qualche motivo ce ne sarà sempre un altro disponibile. Gli alias che vedete sono per i file uploadati dagli utenti tramite l’applicazione, i file statici del sito e i file statici per il backend amministrativo (per questi ultimi dovete dare il path alla cartella di installazione di Django). Dopo aver salvato questo file create un link simbolico nella cartella effettiva dei siti di nginx:

ln -s /etc/nginx/sites-available/mydomain.com /etc/nginx/sites-enabled/mydomain.com

Per avviare gunicorn, essendo su ubuntu, utilizziamo upstart il nuovo sistema per avviare tasks e servizi all’avvio del sistema. Creiamo il file /etc/init/gunicorn_8200.conf e copiamo le seguenti istruzioni:

description "Gunicorn Django on 127.0.0.1:8200"
start on runlevel [2345]
stop on runlevel [06]
respawn
respawn limit 10 5
exec /usr/local/bin/gunicorn_django --bind=127.0.0.1:8200 --workers=2 --access-logfile=/var/log/gunicorn/8200_access.log --error-logfile=/var/log/gunicorn/8200_error.log --daemon /srv/django_srv/mydomain/app/settings.py

Con queste istruzioni diciamo al processo gunicorn di ripartire in caso di crash (respawn) di rispondere all’indirizzo 127.0.0.1 sulla porta 8200 (–bind) di partire come demone (–daemon) e gli diamo i percorsi dei file di log e del file di settings della nostra applicazione.

A questo punto riavviamo il server per verificare che anche upstart funzioni:

shutdown -r now

Il gioco è fatto e la nostra applicazione è pronta per essere utilizzata. I file del progetto django (in base a questa configurazione) devono risiedere in /srv/django_srv/mydomain/app, mentre i file di upload sono in /srv/django_srv/mydomain/uploads per fare in modo che non siano all’interno dell’applicazione e che siano facilmente backuppabili ;)

Spero di essere stato esaustivo, di sicuro con questa configurazione vi potrete accorgere del notevole risparmio di ram rispetto ad un classico stack che utilizza apache come webserver.

Commenti annidati in wordpress

In questi giorni sono ritornato a lavorare un po’ sul mio amato wordpress.

Oltre a segnalarvi un fantastico restyle grafico del tema di backend per l’amministrazione del blog che potete trovare aggiornando wordpress alla versione 3 oggi voglio parlarvi di come modificare il tema dei commenti.

Questa piccola modifica servirà per visualizzare i commenti annidati, ossia far comparire le risposte ad un commento all’interno del commento stesso, per migliorare la discussione e permettere a chi legge per la prima volta tutti i commenti, chi ha risposto a chi e così via.

WordPress ammette di default una profondità di 5 commenti annidati, ma potete impostarla a piacere tramite il menu “Impostazioni”->”Discussione”.

Se utilizzate uno dei tanti temi scaricati dall’archivio di wordpress verificate solamente che il tema sia aggiornato e di norma dovrebbe già includere questa funzione.

Se invece come me sviluppate spesso temi partendo da zero e partite da un tema semplice e magari non aggiornato alle ultime versioni, dovrete compiere alcuni semplici passi:

  1. Nell’header.php (il file della testata), aggiungete una riga sopra al “wp_head()” con questo codice:
    <?php if( is_singular() ) wp_enqueue_script( ‘comment-reply’ ); ?>
  2. Nel file comments.php dove troverete il tag “ol” con all’interno il tag “li” che ha come classe css “comment” sostituite tutto il blocco con la semplice riga
    <ol class="commentlist">
    <?php wp_list_comments(); ?>
    </ol>
  3. A questo punto non vi resta che editare il vostro css e inserire uno stile personalizzato per i vari livelli di profondità dei commenti, per selezionare il tag “li” relativo al tag “ul” dei commenti inserite in testa al selettore css la classe “.commentlist” e il gioco è fatto!

In pochi e semplici passi avrete così una più chiara visione dei commenti e soprattutto della discussione.

Da notare è che il requisito minimo per poter sfruttare questa funzionalità è quello di avere wordpress 2.7 o versione superiore.

Installare Django 1.3 su Mac OS X 10.7 Lion e XAMPP 1.7.3

Se anche voi come me siete curiosi utilizzatori di mac, in questi giorni sarete sicuramente stati tentati di installare l’ultima versione di OS X, ovvero la major release 10.7 denominata “Lion”.

Se non avete ancora provveduto all’aggiornamento, ma siete in procinto di farlo, vi consiglio quest’ottima guida di macitynet (onde evitare problemi al primo avvio di Lion).

Terminato l’aggiornamento sembrava tutto apparentemente funzionante, fino a quando non ho tentato di avviare il server di sviluppo di django. Non ricordo con precisione l’errore ma il succo era che il driver per la connessione al db non era più funzionante. Ingenuamente ho disinstallato mysql-python(conosciuto anche come mysqldb) credendo fosse sufficiente una reinstallazione…. ripeto: ingenuo. ;-)

Lanciando il comando:

sudo python setup.py build

ottenevo una sbrodolata di errori relativi a librerie gcc. A fiuto ho quindi reinstallato xcode (scaricabile gratuitamente dall’app store) e rilanciato la build di mysql-python… ancora errori, ma quelli precedenti sembravano risolti. Ora le rogne venivano dal mysql_config mancante… Ho scoperto che nella cartella di installazione di mysql-python c’è un file site.cfg che contiene questa famosa variabile mysql_config, la quale deve contenere il path al file mysql_config (file di configurazione di mysql). Per me che uso XAMPP 1.7.3 su mac questo file si trova in “/Applications/XAMPP/xamppfiles/bin”.

Lanciando la build del driver ottengo errori dovuti alla mancanza degli headers di mysql, errore che avevo già riscontrato nell’installazione di Imagick su XAMPP per Mac, vado per cui diretto sul sito di XAMPP 1.7.3, scarico il development package e lo installo.

Sperando nella buona sorte rilancio per l’ennesima volta la build di mysql-python e incappo nell’ennesimo errore. Questa volta sembra che sia dovuto ad una errata versione di XCode, ma leggendo più approfonditamente noto che il problema è dovuto al mancato supporto power-pc (ppc) a partire da XCode 4. Per risolvere questo ennesimo problema si deve editare il famoso mysql_config (in “/Applications/XAMPP/xamppfiles/bin” per chi usa XAMPP) nel seguente modo.

Alla riga 97 sostituite la versione minima di mac osx, io ho modificato da 10.4 a 10.6 (vedete voi), la mia riga ora è così:

ldflags='-L/Applications/XAMPP/xamppfiles/lib -I/Applications/XAMPP/xamppfiles/include -mmacosx-version-min=10.6 '

Alla riga 122 riportate la versione di mac appena modificata e inoltre eliminate la voce -arch ppc, la mia riga ora si presenta così:

cflags="-I$pkgincludedir  -I/Applications/XAMPP/xamppfiles/include -L/Applications/XAMPP/xamppfiles/lib -mmacosx-version-min=10.6 -arch i386 -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT  -DDONT_DECLARE_CXA_PURE_VIRTUAL " #note: end space!

A questo punto lanciate la build e per magia arriverà fino al termine senza più errori. Potete quindi installare il pacchetto lanciando il comando:

sudo python setup.py install

A questo punto django sarà tornato alla normalità (a meno che voi utilizzaste le python image library, PIL, per cui dovrete reinstallare anche quelle, ma io non ho riscontrato problemi nel farlo).

Installare tomcat 6 e postgresql 8.4 su ubuntu server 10.04

L’ambiente più familiare (lato server) per realizzare applicazioni web su linux è senza ombra di dubbio un server LAMP (Linux Apache MySQL PHP).

Ormai lo si riesce ad installare senza grosse difficoltà anche in ambiente linux, grazie (ancora una volta) ad ubuntu che mette a disposizione e ci configura tutti i pacchetti necessari per avere un ambiente completamente funzionante.

A volte risulta però necessario uscire dal seminato, cambiando magari DBMS o linguaggio di programmazione. Vuoi perchè si vuole avere un db più simile ad Oracle o vuoi perchè si preferisce un linguaggio più strutturato o più familiare ai programmatori.

Mi è successo alcuni giorni fa di provare a configurare sul mio server di casa, un ubuntu server 10.04 LTS, un gestionale web scritto in java compatibile con sql server o postgresql. Visto che, come saprà chi mi conosce, non amo molto le tecnologie microsoft e che non credo si riesca ad installare sql server su linux, ho deciso di buttarmi su postgresql ;-)…

Dovremmo quindi installare tomcat per avere un server web java e postgresql per il lato database.

Per prima cosa, assicuriamoci di avere il java development kit di Sun installato:

sudo apt-get install sun-java6-jdk

Ora possiamo procedere con l’installazione del server web tomcat:

sudo apt-get install tomcat6
sudo apt-get install tomcat6-admin

Una volta installati questi pacchetti il nostro server web sarà pronto per essere utilizzato e amministrato, potete verificarne il funzionamento digitanto da browser http://ip_server:8080/, dove ipserver sarà l’indirizzo ip della macchina su cui avete installato tomcat.

Per poter entrare nella sezione di amministrazione delle applicazioni installate in tomcat e verificare lo stato del server, si dovrà creare un utente e fornirgli i privilegi di amministrazione. Per fare ciò editate il file /etc/tomcat6/tomcat-users.xml inserendo le seguenti linee:

<role rolename="admin"/>
<role rolename="manager"/>
<user username="admin" password="admin" roles="admin,manager"/>

Tomcat su linux usa di default le openjdk ovvero le jdk java open source e non quelle ufficiali sun, perciò potreste incorrere in problemi di incompatibilità se installate software non testato su questa piattaforma, per modificare le jdk usate editate il file /etc/default/tomcat6/ e alla voce JAVA_HOME sostituite la linea con questa:

JAVA_HOME=/usr/lib/jvm/java-6-sun

Bene, ora che il server è installato e configurato possiamo passare all’installazione di postgresql:

sudo apt-get install postgresql

Ora che postgresql è installato configuriamo gli indirizzi ip sui quali il db server sarà in ascolto. Potrebbe non essere necessario fare questa configurazione se non desiderate gestire postgresql dall’esterno, ma pgadmin è un tool di gestione per postgresql davvero comodo. Editate quindi il file /etc/postgresql/8.4/main/postgresql.conf così:

listen_addresses = 'localhost,<em>ip_server</em>'

Dove ip_server sarà sempre l’ip della macchina su cui avete installato postgre.

Ora inseriamo la password per l’utente default postgres:

sudo -u postgres psql template1

Si aprirà la shell di postgre e dovremo eseguire la query:

ALTER USER postgres with encrypted password 'password';

Fatto ciò possiamo editare il file dei permessi di postgre /etc/postgresql/8.4/main/pg_hba.conf:

local   all   all   md5
host   all   all   192.168.0.0/24   md5

A questo punto possiamo riavviare sia tomcat sia postgre:

sudo /etc/init.d/tomcat6 restart
sudo /etc/init.d/postgresql-8.4 restart

…e andare a posizionare le nostre applicazioni in /var/lib/tomcat6/webapps/ e gestire i database da shell o tramite pgadmin ;-)

Il blog si rifà il look!

Come avrete potuto notare visitando il mio blog, da oggi c’è una nuova grafica ad accogliervi!

Ho lavorato qualche giorno(ma soprattutto qualche notte :-P) per realizzare il nuovo tema wordpress, cercando di seguire le linee guida dettate dal mio amico architetto Ermal Brahimaj.

Discutendo insieme di cosa doveva avere il mio blog, e di come doveva essere realizzato, mi ha dato alcune brillanti idee, analizzando il mio sito sotto il punto di vista di un utente che vede per la prima volta questo spazio. Il design è minimal (spero piacerà anche a @marcoviti ;-) ) e utilizza solamente una scala di grigi. Ho eliminato tutto il superfluo, in modo che il lettore si possa concentrare solamente sul contenuto, il vero “succo” di questo sito. Proprio per accentuare questo concetto, (se provate a spostare il mouse sul testo dell’articolo ne avrete la prova) ho utilizzato jQuery per far “scomparire” il superfluo, ovvero il banner il menu e la ricer ca, così che il lettore non abbia distrazioni. Inoltre non ci sono linee che delimitino lo spazio del sito, proprio dare la sensazione di libertà, di respiro.

Spero piaccia anche a voi questo restyling, in ogni caso ringrazio davvero il mio amico Ermal per le idee che mi ha dato e vi invito, se non lo avete ancora fatto, a visitare il suo sito brahimaj.com e la sezione progetti per dare un’occhiata ai suoi lavori!

Preparare un web server per django su ubuntu server 10.04

Poco tempo fa ho scoperto il favoloso mondo di Django, un web framework che consente di scrivere meno codice e creare applicazioni python davvero molto efficienti.

Oltre ad essere un framework che implementa l’MVC(Model View Controller), la caratteristica che mi ha attratto maggiormente è una fantastica funzionalità di ORM(Object Relational Mapping).. cosa significa? In poche parole nel file che implementa il “Model” (models.py) dovrete dichiarare gli oggetti che verranno trasformati in tabelle del vostro database, al resto penserà django. Infatti una volta collegato un db e scritte le classi del modello, con la funzione syncdb verranno create le tabelle residenti sul db. Vi rimando però al tutorial ufficiale per capire davvero qualcosa in più su questo fantastico framework…

In questo post vi farò vedere i pochi e semplici passi per configurare un web server adatto ad ospitare un’applicazione django. Ovviamente il server linux girerà grazie ad ubuntu server ed in particolare nella versione LTS(long term support) 10.04. Salterò ovviamente i passi dell’installazione vera e propria del sistema operativo (anche perchè ormai è a prova di win-user :-P ).

Partendo da un sistema pulito, su cui non è stato installato nessun componente, dovremo per prima cosa assicurarci che il sistema sia aggiornato:

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get upgrade

Fatto ciò possiamo procedere con l’installazione dei componenti necessari a mettere in piedi un server web, il che equivale ovviamente ad installare il buon vecchio Apache:

sudo apt-get install lamp-server^

In questo modo installeremo tutti i pacchetti per avere un server LAMP ovvero con apache come detto, e con mysql per la parte di database (verrà installato anche php5 per poter utilizzare phpmyadmin, l’interfaccia per la gestione da web di mysql)

Attesi i dovuti tempi per lo scaricamento, l’installazione e la configurazione dei vari pacchetti (vi verrà chiesta la password per mysql) dovreste avere il vostro server web funzionante (potete testarlo collegandovi da un qualsiasi browser nella rete all’indirizzo ip del server es: http://192.168.0.1 ).

Bene, ora manca un ultimo componente per avere il server pronto: il mod_wsgi ovvero il modulo apache per l’interpretazione del codice python:

sudo apt-get install libapache2-mod-wsgi

Ora non ci resta che installare il driver per fare comunicare python e mysql, che come detto sarà per comodità il nostro dbms:

sudo apt-get install python-mysqldb

Ora possiamo procedere al download e installazione del framework dal sito ufficiale di django(vi risparmio il “wget”, mi sembrava troppo da nerd, ma si può fare ;-) ). Trasferite il tar.gz sul server se non è già lì, e scompattatelo (tar -xvzf nomefile.tar.gz per i newbie). Ora entrando nella cartella che avete ottenuto dalla scompattazione potete installare django:

sudo python setup.py install

Vi consiglio spassionatamente di installare la release ufficiale di django e non quella dagli archivi ubuntu per un puro fatto di aggiornamento della versione, infatti sul canale ufficiale sarete sicuri di avere l’ultima stable-release mentre ubuntu è sempre più indietro in queste cose…

Bene adesso abbiamo tutto ciò che ci serve(r) (battuta di bassissimo umorismo, non ci fate caso, è l’età :-P ).

Procediamo con la creazione del file python che darà le direttive al mod_wsgi sui percorsi della nostra applicazione, nella cartella del nostro progetto, creiamo il file django.wsgi:

vim /home/user/py-srv/applicazione1/django.wsgi

Ipotizzando che la nostra applicazione risieda in /home/user/py-srv/applicazione1 …

Il file dovrà contenere il seguente codice:

import os
import sys

sys.path.append('/home/user/py-srv/applicazione1')

os.environ['PYTHON_EGG_CACHE'] = '/home/user/py-srv/.python-egg'
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

Ora dobbiamo solamente dire ad apache quale sarà la cartella della nostra applicazione. Per fare ciò editiamo il file default nella cartella sites-available di apache (prima però facciamo una copia del file per sicurezza ;-) ) :

sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/default.old
sudo vim /etc/apache2/sites-available/default

Il file dovrà contenere le seguenti configurazioni:

<VirtualHost *:80>
   DocumentRoot /home/user/py-srv/applicazione1/public_html

   WSGIScriptAlias / /home/user/py-srv/applicazione1/django.wsgi
   <Directory /home/user/py-srv/applicazione1>
      Order allow,deny
      Allow from all
   </Directory>

   Alias /favicon.ico /home/user/py-srv/applicazione1/public_html/favicon.ico
   Alias /images /home/user/py-srv/applicazione1/public_html/images
   Alias /static /home/user/py-srv/applicazione1/public_html/static

   ErrorLog /home/user/py-srv/applicazione1/logs/error.log
   CustomLog /home/user/py-srv/applicazione1/logs/access.log combined
</VirtualHost>

Come potete immaginare la cartella “public_html” sarà quella che conterrà i file html pubblici, ovvero i file del template della vostra applicazione.

Bene, se avete fatto tutto nel modo giusto, vi basterà collegarvi all’indirizzo ip che avete già usato prima per testare apache, e vedrete come per magia che funzionerà tutto!

(non funziona? non fate come me che avevo lasciato il vecchio path nel file settings.py, e ci ho perso mezz’ora per accorgermene :-P )

Buon divertimento!

Creare un web service con SOAP e PHP

Ai tempi dell’università, nel corso di programmazione in rete tenuto dal Prof. Matteo Baldoni, avevamo realizzato un ottimo progetto in Java di agenti che interagivano tra di loro.
Era anche questo una specie di servizio web anche se era realizzato con RMI ovvero Remote Method Invocation, ossia una funzione di java che consente di invocare metodi di oggetti remoti da altre java virtual machine.

Oggi visto che sono ancora a casa per l’influenza, ho deciso di documentarmi sui web services in php, dato che probabilmente dovrò realizzare un progetto in cui potrebbero tornarmi utili.

Seguendo l’ottima guida “PHP 6, Guida per lo sviluppatore” di Lecky-Thompson, Novicki e Myer (ve la consiglio vivamente se siete interessati all’argomento, è davvero ottima), ho deciso di riprodurre l’esempio di un client-server SOAP(Simple Object Access Protocol). Innanzitutto SOAP è un protocollo per lo scambio di messaggi tra agenti software, ossia un client tramite soap può richiamare funzioni di un server inviando e ricevendo parametri. E fin qui nulla di strano mi direte voi… Infatti, la cosa interessante deve ancora arrivare! La peculiarità di scrivere software implementando SOAP è che client e server possono essere scritti in linguaggi diversi, essendo quest’ultimo appunto un protocollo e non una componente software. Tutti i linguaggi più comuni hanno delle classi che implementano SOAP, sia lato server sia lato client. Diventa così facile capire che una volta scritto un server SOAP che implementa alcune funzioni, possono esserci N client che sfruttano queste funzioni per leggere dati comuni o interagire con applicazioni sul web.

Ecco allora che ci spieghiamo come sia possibile che tutte le applicazioni web più famose, da quelle di google, a facebook fino a twitter, mettano a disposizione metodi per interagire dall’esterno con i loro servizi (le famose API, Application Programming Interface).

Come vi dicevo ho messo in pratica l’esempio che ho trovato sulla guida di PHP, potete raggiungerla a questo indirizzo. L’esempio non fa altro che realizzare un server che ha un metodo che prende in input un nome e restituisce un saluto, comprensivo del nome inviato. Il client ovviamente preso in input il nome invia la richiesta al server e stampa il saluto ricevuto. Nulla di complicato, ma si riescono ad intuire le potenzialità di questo protocollo.

I due script in php come vedrete fra poco, sono molto semplici, e non richiedono più di una decina di righe di codice ciascuno, la parte fondamentale di questo esempio è però il file wsdl, ossia il file xml di dichiarazione dei metodi messi a disposizione dal server. Questo file non è indispensabile ma è utile a chi implementa i client per sfruttare tutte le funzioni messe a disposizione da SOAP.

Come vi dicevo dal lato server il codice php è semplice:

function sayHello($name){
    $salutation="Ciao ".$name.", sarai lieto di sapere che sto funzionando!";
    return $salutation;
}
$server= new SoapServer("test.wsdl");
$server->addFunction("sayHello");
$server->handle();

Il file xml per le dichiarazioni è invece un po’ più complesso ma con un po’ di attenzione non sarà difficile comprenderne il significato:

<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="test"
targetNamespace="http://URL_CARTELLA_SERVER_SOAP"
xmlns:tns="http://URL_CARTELLA_SERVER_SOAP"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/">

    <message name="sayHelloRequest">
        <part name="name" type="xsd:string"/>
    </message>
    <message name="sayHelloResponse">
        <part name="salutation" type="xsd:string"/>
    </message>

    <portType name="sayHelloPortType">
        <operation name="sayHello">
            <input message="tns:sayHelloRequest" />
            <output message="tns:sayHelloResponse" />
        </operation>
    </portType>

    <binding name="sayHelloBinding" type="tns:sayHelloPortType">
        <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http" />
        <operation name="sayHello">
            <soap:operation soapAction="" />

            <input>
                <soap:body use="encoded" namespace="" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
            </input>
            <output>
                <soap:body use="encoded" namespace="" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
            </output>
        </operation>
    </binding>
    <documentation>UNA VOSTRA DESCRIZIONE DEL SERVIZIO</documentation>
    <service name="sayHelloService">
        <port name="sayHelloPort" binding="sayHelloBinding">
            <soap:address location="http://URL_SCRIPT_PHP_SERVER_SOAP" />
        </port>
    </service>
</definitions>

Fatto ciò, non ci resta che scrivere il codice per il client (tralascio il banale form html, ma metto a disposizione lo zip con tutto dentro):

$wsdl_url="http://URL_AL_DEL_FILE_WSDL";
if(isset($_POST['name'])){
    if($_POST['name']!=null){
        $client=new SoapClient($wsdl_url);
        print_r($client->sayHello(htmlentities($_POST['name'])));
    }
}

La cosa fondamentale per poter utilizzare SOAP è che il vostro php abbia l’estensione php_soap abilitata, ma se ho capito bene, da php6 viene inclusa di default tra le funzioni del core di php. Tra l’altro essendo inclusa nelle funzioni default di php è scritta in C per cui molto più veloce rispetto a scrivere codice php, di conseguenza, in queste applicazioni l’unico collo di bottiglia potrebbe essere la lentezza della linea o i tempi di ping/risposta di client e/o server.

Se siete pigri e volete testare il codice senza dovervi sbattere, eccolo qui, pronto per voi già impacchettato ;-)

Prossimamente testerò anche REST un altro metodo per realizzare web service con meno rogne, non serve infatti nessun file di dichiarazione, ma anche meno rigido e controllato.

Inserire pulsanti “sociali” nel proprio sito

Facebook Like e Google Buzz
Per celebrare le (quasi) 1000 visite mensili del blog e ringraziarvi ho deciso di implementare una nuova funzionalità.

Da oggi potete condividere gli articoli del blog che vi piacciono su facebook o buzz, cliccando sulle icone nel riquadro grigio al fondo dei post.

Per quanto riguarda facebook, l’inserimento del plugin prevede l’utilizzo delle Facebook javascript SDK. Per prima cosa si deve registrare il proprio sito come applicazione, in modo da ottenere un “application id”. Una volta fatto ciò potete aggiungere in fondo alla vostra pagina il codice javascript per caricare le sdk:

<div id="fb-root"></div>
<script>
  window.fbAsyncInit = function() {
    FB.init({appId: 'your app id', status: true, cookie: true,
             xfbml: true});
  };
  (function() {
    var e = document.createElement('script'); e.async = true;
    e.src = document.location.protocol +
      '//connect.facebook.net/en_US/all.js';
    document.getElementById('fb-root').appendChild(e);
  }());
</script>

Ora potete aggiungere il tag FBML che caricherà il pulsante “mi piace”:

<fb:like href="URL da segnalare" layout="button_count"></fb:like>

Potete personalizzare il tipo di pulsante tramite il tag “layout”:

  • “standard” per avere il pulsante con la frase a fianco
  • “button_count” per avere il pulsante con il contatore dei “like”
  • “box_count” per avere il pulsante e il contatore su due righe diverse

e tramite il tag “colorscheme”:

  • “light” per lo schema di colori default
  • “dark” per lo schema di colori grigio scuro

Nel tag href dovete inserire l’url che volete sia segnalata quando qualcuno clicca sul pulsante.

Per quanto riguarda Google buzz invece, non è necessario registrare nessuna applicazione, si dovrà solamente includere il codice javascript per le Google Buzz SDK in fondo alla pagina:

<script type="text/javascript" src="http://www.google.com/buzz/api/button.js"></script>

e il codice del pulsante per condividere il link

<a href="http://www.google.com/buzz/post"
  class="google-buzz-button" title="Google Buzz"
  data-message="Here’s Buzz!"
  data-url="http://www.google.com/buzz"
  data-locale="it"
  data-button-style="normal-count"></a>

È anche possibile personalizzare il pulsante modificando il tag “data-url” inserendo l’url alla pagina che si vuole segnalare, e il tag “data-button-style” con le seguenti voci:

  • normal-count
  • small-count
  • normal-button
  • small-button
  • link