Si tratta di un software gratuito che gira su piattaforme Linux, Windows (Apache).

Permette la completa gestione dei rapporti commerciali, tra voi e i vostri clienti, attraverso il sistema basato sui trouble tickets.

Distribuito sotto licenza MIT ha le seguenti caratteristiche:

• - Valid css e xhtml strict;
• - unobtrusive javascript utilizzando il framework jQuery;
• - multilanguages;
• - aggiungi/edita/cancella/chiudi/assegna trouble tickets e risposte;
• - nessuna limitazione sul numero di utenti, amministratori e staff di supporto;
• - permessi agli operatori, accesso separato utenti;
• - gruppi di operatori con gestione permessi (CRUD);
• - illimitate e nested categories;
• - paging;
• - moduli di ricerca;
• - tables sortable;
• - nessun limite sul numero di TT creabili.

Potete visionare una demo qui.

E' possibile ad esempio effettuare una ricerca con parole chiave, ed è di questo di cui ci occuperemo in questo tutorial, ma è anche possibile recuperare la playlist di un dato utente o i videos preferiti dagli utenti.

Lo Zend Framework mette a disposizione Zend GData che è una interfaccia per accedere (leggere o scrivere) a tutti i web services ospitati da Google.

In questo tutorial si accederà al feed per mezzo delle DOM Functions potete visionare una demo qui.

Rimando il lettore che ancora non ne conoscesse l'uso a jQuery HowTo's,1.1.2 API Browser e all'ottimo articolo What is this? in cui si spiega il riferimento this in jQuery.

Ai più curiosi ed esperti si consiglia la lettura di Roll out your own JavaScript Interfaces del legendario Dustin Diaz in cui con disarmante facilità si illustra un 'semplice' esempio di come possa funzionare jQuery (credetemi saranno molte le lucine che si accenderanno nel vostro cervello ;) dandovi uno spunto per un nuovo modo di programmare in javascript).

Lo script utilizza l'Object Initializers anche conosciuta come JavaScript Object Notation per implementare un oggetto Poll che contiene tutte le proprietà/metodi necessari al suo funzionamento potete visionare una demo qui.

Nel modulo cambia password, viene richiesto in input l'email dell'utente (si spera che almeno la sua email la ricordi ;) ) e se nel database è presente un record contente questo valore, aggiorniamo l'uid ed inviamo una email con un link per accedere al modulo reset password che si incaricherà del reset vero e proprio.

La classe per l'autentificazione è sviluppata direttamente nel model ed è divisa in due, una classe per il login e una classe per la verifica, come potete constatare le due classi sono molto concise, ma svolgono egregiamente, almeno penso ;), il loro compito.

E' superfluo dire che se il valore non è presente nel database la registrazione non viene confermata.

Nel file config-settings-inc.php sono definite una serie di costanti tra cui FROM_MAIL (email di riferimento del vs. sito), WEB_SITE_NAME (il nome del vs. sito) e WEB_SITE_URL (base name dell'url del vs. sito) che vanno settate con i giusti valori per un corretto funzionamento dello script.

Al momento della spedizione della form, lo script oltre ad inserire i dati dell'utente, inserisce un uid che serve da seme/controllo per la conferma della registrazione tramite GET.

Al momento della conferma aggiorneremo l'uid associato e setteremo il campo user_confirm ad 1 nella tabella users permettendo il login al ns. nuovo utente.

Il controller riceve i comandi dell'utente (in genere attraverso la view) attraverso una richiesta HTTP. Esamina cosa riceve nella richiesta HTTP, ad esempio una serie di variabili GET, e risponde nel modo appropriato.

Lo script ha una pagina dedicata per ogni azione dell'utente, questo per rendere il suo sviluppo più lineare, ma avremo potuto implementare una variabile GET (action), gestita da un controller centrale che inoltra la richiesta ai vari sub-controller.

Il suo compito è quello di trasformare semplici dati, in dati che contengono qualche sorta di informazione per poi inviarli alla adeguata view (solitamente tramite il controller).

Nella maggior parte dei casi esso ha al suo interno queries per il database effettuate tramite una classe di astrazione del database (nel ns. caso PDO).

Quando si parla delle views molta gente pensa ai templates ma non necessariamente, dobbiamo utilizzare un complesso template engine tipo Smarty per raggiugere il ns. scopo, che è quello di fornire una interfaccia alla ns. applicazione.

Sull'opportunità dell'uso dei templates engine si sono accese molte discussioni, rimando il lettore all'articolo PHP and Templates, in cui sono analizzati i vari pro e contra del loro utilizzo.

Per quei lettori interessati a saperne di più rimando a questa ottima serie di articoli.

Potrai inoltre cogliere tutta la potenza e la versabilità del Model View Controller seguendo lo sviluppo di una completa applicazione web.

Puoi trovare la demo qui.