In questo articolo si inizierà a parlare specificamente delle tecnologie Web 2.0: l‘argomento trattato sarà Ajax. Tramite alcuni esempi, vedremo tra l‘altro come funziona il suo sistema asincrono di gestione del collegamento tra client e server.

Introduzione

Nell’articolo [MOKAWEB2_I] è stato introdotto il Web 2.0, parlando degli aspetti tecnologici e sociali, fornendo una visione introduttiva delle tecnologie relative al nuovo modo di intendere il Web. Nello scorso articolo [MOKAWEB2_II] si è parlato di Wiki, lo strumento che maggiormente ha contribuito alla diffusione del Web 2.0. In questo articolo si inizierà a parlare specificamente delle tecnologie Web 2.0; l’argomento trattato sarà Ajax.

AJAX

AJAX è l’acronimo di Asynchronous JavaScript and XML:

• A = Asynchronous: è il tipo di colloquio tra Client e Server
• JA = JAvascript: è il linguaggio che viene utilizzato dal browser per comunicare con il Server
• X = Xml: il formato dei dati che transitano tra Client e Server.

Lo scopo principale di AJAX è di rendere i siti più usabili, interattivi e funzionali. Il termine AJAX non si riferisce a un’unica tecnologia, ma raggruppa un insieme di tecniche e tecnologie:

• HTML e CSS per il markup e lo stile
• DHTML per il contenuto dinamico
• DOM (Document Object Model)
• XMLHttpRequest, l’oggetto per l’interscambio asincrono dei dati tra browser e web server
• XML come formato dati

Le applicazioni tradizionali Web basano il loro funzionamento su un protocollo Request-Response. L’utente effettua una Request verso il server a fronte di una specifica azione (click su un link, su un bottone, su un’immagine, etc.), il Server riceve i dati di un Form (via GET o POST), effettua una elaborazione dei dati, e invia al Client una nuova pagina Web che andrà a sostituire (o a ricaricare) la pagina precedente. Questo meccanismo è di tipo prettamente sincrono, vale a dire che il Client, per proseguire la sua elaborazione, deve aspettare che il Server abbia concluso l’elaborazione e preparato la pagina HTML di output.

AJAX introduce un’indirezione tra il Client e il Server per rendere la comunicazione più interattiva e performante. In sostanza AJAX disaccoppia la comunicazione tra Client e Server rendendo possibile una comunicazione tipo asincrono, vale a dire che il Client non interagisce direttamente con il Server ma lo fa invece con l’engine AJAX, che si occupa di dialogare con il Server. Il Client preleva i dati da un eventuale oggetto Form e li passa allo strato AJAX. Nell’interfacciarsi con l’engine AJAX, il Client specifica la funzione di callback associata a un determinato evento, al verificarsi del quale verrà richiamata dall’engine AJAX. In questo modo, l’utente non dovrà più attendere che la pagina venga ricaricata, ma semplicemente la vedrà cambiare davanti ai sui occhi contestualmente ai dati che sta immettendo nella Form.

Figura 1 – Confronto di applicazioni web tradizionali e applicazioni basate su AJAX 

L’idea alla base delle tecnologie AJAX è di sfruttare un particolare oggetto: l’XMLHttpRequest che è incluso nei browser (un tempo era disponibile solo come ActiveX in Internet Explorer). L’oggetto XMLHttpRequest consente di gestire il flusso dei dati tra il Client e il Server indirizzando la risposta del server su uno o più elementi della pagina stessa senza doverla ricaricare. Esemplificando quanto detto, si pensi di avere una pagina Web che deve gestire il controllo della validità sintattica dell’indirizzo email.

Figura 2 – Caso d’uso d’esempio

Con le tecnologie Web tradizionali si esegue una Post a una Servlet con l’indirizzo e-mail da controllare.

    
        Email:
        value="" size="16" onChange=checkEmail(this.form)>
        

    
    
        Press to submit:
        
        
    
    
    . . . 

La Servlet Java evade la richiesta invocando (forward) la successiva vista (pagina JSP e relativo View Bean) contenente l’esito dell’elaborazione.

public class CheckEmailServlet extends HttpServlet {
    public void doPost(HttpServletRequest request, HttpServletResponse response) 
throws  ServletException, IOException {
        String nextPage = "";
        String emailParam = request.getParameter("email");
        boolean retValue = MailChecker.isEmailValid(emailParam);
        if (retValue) {
            nextPage = "/success.jsp";
        }
        else {
            ErrorViewBean errorViewBean = new ErrorViewBean("Email NON valida!");
            request.setAttribute("errore", errorViewBean);
            nextPage = "/emailForm.jsp";
        }
        // configurazione della Response HTTP
        response.setContentType("text/html");
        response.setHeader("Pragma", "No-cache");
        response.setDateHeader("Expires", 0);
        response.setHeader("Cache-control", "no-cache");
        // Dispatch della Next View
        RequestDispatcher rd = this.getServletContext().getRequestDispatcher(nextPage);
        rd.forward(request, response);
    }
}

Il medesimo esempio, sviluppato con AJAX, prevede una risposta puntuale da parte della Servlet che, nell’esempio proposto, risulta essere un semplice boolean (true/false) riguardante la validità della e-mail. La Servlet quindi si occupa di gestire il subset strettamente necessario e, rispetto al caso precedente, diventa:

public class NewCheckEmailServlet extends HttpServlet {
    public  void doPost(HttpServletRequest request, HttpServletResponse response) 
throws IOException, ServletException {
        // configurazione della Response HTTP
        response.setContentType("text/xml");
        response.setHeader("Cache-Control", "no-cache");
        String emailParam = request.getParameter("email");
        boolean retValue = MailChecker.isEmailValid(emailParam);
        if (retValue) {
            response.getWriter().write("true");
        } else {
            response.getWriter().write("false");
        }
    }

Lato Client non si ha più un Form che effettua il post automatico di tutti i campi, bensì si utilizza l’oggetto XMLHttpRequest per inviare al server il solo campo d’interesse, che nell’esempio è rappresentato dall’indirizzo e-mail:

. . .

 

 

 

 

Figura 3 - Il traffico di rete dell'esempio proposto, sviluppato con Ajax.

Nell'esempio riportato è stata implementata in modo esplicito la gestione della comunicazione Client/Server attraverso l'utilizzo di JavaScript e dell'oggetto XMLHttpRequest. L'utilizzo di JavaScript sulla pagina Web comporta una più difficile fase di debugging / test in fase di sviluppo, di monitoring e di manutenzione.

Esistono prodotti open source che permettono di nascondere i dettagli implementativi javascript agevolando quindi lo sviluppo. Lo stesso esempio verrà ora sviluppato mediante l'utilizzo di due differenti strumenti open source: DOJO e Google Web Toolkit. Il primo esempio utilizzerà le librerie JavaScript di DOJO, mentre il secondo usufruirà delle funzionalità del toolkit Google. In entrambi gli esempi, lato Server, verrà utilizzata sempre la stessa Servlet (NewCheckEmailServlet) precedentemente spiegata.

 Figura 4 - Uno sguardo d'insieme all'esempio proposto: JavaScript, Libreria e Toolkit

DOJO

Dojo [DOJO] è un toolkit Open Source DHTML scritto in JavaScript che permette la creazione di funzionalità dinamiche nelle pagine web e in ogni altro ambiente che supporti JavaScript. DOJO organizza le sue funzionalità su un sistema di package. Quando si costruiscono script con DOJO, si possono includere le sole API necessarie al proprio sviluppo.

L'utilizzo di DOJO semplifica quindi l'interfaccia con l'oggetto XMLHTTPRequest mediante apposite librerie (analogamente a quanto visto in [MOKAJAX_II] con la libreria Sarissa). Innanzi tutto è necessario importare la libreira JavaScript dojo.js all'interno della pagina.

Dopodichè possono essere specificati i moduli o package di riferimento: operazione, questa, non obbligatoria ma utile per "incrementare le perfomance di caricamento".

A questo punto si sostituisce il precedente codice JavaScript del metodo validate() con il seguente:

        
        
Moka Check Email

        






    

A questo punto si procede sviluppando la classe Java con le API di GWT (com.google.gwt.*).

public class Hello implements EntryPoint {
    // Metodo entry point
    public void onModuleLoad() {
        final Label label = new Label();
        final TextBox textBox = new TextBox();
        final Button button = new Button("Check Email");
        button.addClickListener(new ClickListener() {
            public void onClick(Widget sender) {
                if (textBox.getText().equals("")){
                    label.setText("Introdurre Indirizzo e-mail!");
                }
                else {
                    label.setText("");
                    String url 
                    = "http://localhost:8080/sampleAjaxEmailWebApp
    /CheckEmailAjaxServlet?email=" 
                    + textBox.getText();   
                    try {
                        HTTPRequest.asyncGet(url, new ResponseTextHandler() {
                            public void onCompletion(String responseText) {
                                // Nella realtà, questo testo sarebbe sotto 
                                // forma di response RPC. Ma questa tecnica
                                // è comunque ottima per test ed esempi!
                                validateCallback(responseText);
                            }
                            private void validateCallback(String responseText) {
                                Document customerDom = XMLParser.parse(responseText);
                                Element customerElement = customerDom.getDocumentElement();
                                String resultValue = getElementTextValue(customerDom,
                                                                         "valid");
                                if (resultValue.equals("false")) {
                                    // email non valido
                                    label.setText("E-Mail NON VALIDA!!!");
                                } else if (resultValue.equals("true")) {
                                    // email valida
                                    label.setText("E-Mail CORRETTA!!!");
                                } else {
                                    // email valida
                                    label.setText(resultValue);
                                }
                            }
                            private String getElementTextValue(Document parent, 
                                                               String elementTag) {
                                NodeList list = parent.getElementsByTagName(elementTag);
                                Node node = list.item(0);
                                if (node != null){
                                    Node child = node.getFirstChild();
                                    return child.getNodeValue();
                                }
                                else {
                                    return parent.toString();
                                }
                            }
                        });
                    }catch(Exception e){
                        label.setText("Connection to : "+ url +" Refused!!!");
                        e.printStackTrace();
                    }
                } 
            }
        });
        RootPanel.get("slot1").add(textBox);
        RootPanel.get("slot2").add(button);
        RootPanel.get("slot3").add(label);
    }
}

Il client invoca la Servlet mediante la classe HTTPRequest per poi effettuare il parsing della risposta mediante la classe XMLParser. In modo analogo a come si farebbe con una GUI AWT, vengono definiti gli oggetti grafici (in questo caso appartenenti alle librerie GWT) con relativa gestione degli eventi. Stesso discorso vale per l'oggetto HTTPRequest (che in GWT corrisponde a un wrapper dell'oggetto XMLHTTPRequest) alla cui chiamata asyncGet viene passato l'handler ResponseTextHandler(), il cui metodo astratto associato all'evento onCompletion viene ridefinito con l'invocazione della function di callback validateCallback(). In ultimo si procede al posizionamento di tali oggetti grafici. Tale operazione viene attuata associando gli oggetti grafici con gli ID definiti all'interno della pagina HTML, per poi passare all'elaborazione del compilatore per la generazione del layout finale.

Compilando l'esempio con il GWTCompiler e mandandolo in esecuzione con il GWTShellb si ottiene, nella modalità embedded mode, il seguente risultato:

Figura 5 - Esempio proposto, con la parte client sviluppata con GWT

Per effettuarne il deploy su Tomcat occorre copiare i file generati dal compilatore Java-to-Javascript all'interno della directory WebApp. Un simile approccio semplifica sicuramente lo sviluppo a coloro che conoscono Java e non JavaScript. Ma occorre anche tenere in considerazione la mancanza di trasparenza del codice JavaScript generato che, quindi, risulta difficile da trattare per il debug e la manutenzione.

Conclusioni

In questo articolo si è parlato di AJAX mostrando tre possibili modalità di sviluppo, cercando di mettere in evidenza i pro e i contro. Si sono utilizzati l'approccio JavaScript ?puro?, l'approccio mediante libreria JavaScript (DOJO, Sarissa) e infine un approccio mediante toolkit (Google Web Toolkit, Dojo).
Nel prossimo articolo si parlerà di Really Simple Syndication (RSS).

Riferimenti

[MOKAWEB2_I] S. Rossini - G. Morello, "Il Web 2.0. I parte: principi e tecnologie, una visione introduttiva", Mokabyte 117, Aprile 2007

[MOKAWEB2_II] S. Rossini, "Il Web 2.0. II parte: WIKI", Mokabyte 118, Maggio 2007

[MOKAJAX_I] M. Ratto, "Sviluppare Applicazioni AJAX. I parte", MokaByte 107, Maggio 2006

[MOKAJAX_II] M. Ratto, "Sviluppare Applicazioni AJAX. II parte: realizzare applicazioni AJAX utilizzando il progetto Open Source Sarissa", MokaByte 108, Giugno 2006

[MOKAJAX_III] M. Ratto, "AJAX e framework: Sviluppare Applicazioni AJAX con il framework Java Google Web Toolkit", MokaByte 112, Novembre 2006

[WP_AJAX]
http://it.wikipedia.org/wiki/AJAX

[DOJO]
http://dojotoolkit.org/

[GWT]
http://code.google.com/webtoolkit/download.html