X-stream: xml è facile !

Salve a tutti…ebbene sì…si ricomincia. Siccome è passato un pò di tempo dall’ultimo post, inizierò a scrivere così come se niente fosse…così nessuno se né accorgerà  ! Sono alle prese con lo sviluppo di un’applicazione web, che fa uso di XML per la serializzazione dei dati. L’applicazione è scritta in Java, usa Spring come framework di appoggio. La parte fondamentale come dicevo, consiste nella serializzazione dei dati in XML. La struttura XML che deve essere serializzata non è molto complessa, ma neanche troppo semplice…per cui al primo impatto, ho deciso di non appoggiarmi sulle classiche librerie messe a disposizione da Java (xerces) o quelle presenti di default nelle API (javax.xml.parser).
Sono andato così alla ricerca in rete di qualcosa che potesse essermi utile, cercavo qualcosa che fosse facile da usare e al tempo stesso leggero, in modo tale da non appesantire l’applicazione. Ho trovato così XStream, una libreria che permette di serializzare oggetti in XML e viceversa. Il viceversa nel mio caso è fondamentale, dal momento che se possibile inizializzare una struttura dati di oggetti senza dover, materialmente, navigare l’XML mi ha aiutato molto.
Non mi soffermerò molto nel descrivere le caratteristiche della libreria, sopra come avrete notato ho linkato l’URL quindi potete fare da voi…mi concentrerò su qualche feature che mi è sembrata interessante e descriverò qualche esempio pratico.
La creazione di un file XML a partire da un oggetto Java è molto semplice, si parte dalla creazione e inizializzazione dell’oggetto stesso, dopo di ché si procedere richiamando un metodo statico che provvede alla generazione (serializzazione) del file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class Blog {
  private String name;
  private String author;
  private Contacts contacts;
  /* getter&setter + constructor */
}
 
public class Contacts {
  private String email;
  private String url;
  /* getter&setter + constructor */
}
 
XStream xstream = new XStream();
XStream xstream = new XStream(new DomDriver());
 
/* GLi alias rendono la serializzazione più chiara */
xstream.alias("person", Blog.class);
xstream.alias("phonenumber", Contacts.class);
 
Blog blog = new Blog("DevMe", "mulp");
blog.setContacts(new Contacts("mulp@devme.it", "http://www.devme.it"));
String xml = xstream.toXML(blog);

<blog>
    <name>DevMe</name>
    <author>mulp</author>
    <contacts>
    	<email>mulp@devme.it</email>
    	<url>http://www.devme.it</url>
    </contacts>
</blog>

Al contrario, dando in input l’XML prodtto, si ottiene l’oggetto inizializzato:

1

Blog blog = (Blog)xstream.fromXML(xml);

L’esempio di prima dimostra la facilità e la flessibilità d’uso della libreria XStream. Unico particolare degno di nota è il fatto di poter definire degli alias per le classi che permette poi, in fase di serializzazione di poter generare tag coincisi dal nome uguale al nome della variabile membro, a meno che non si chieda di cambiarlo. Per intenderci, se non avessi definito gli alias otterei come tag il nome completo della classe per il tag blog assieme al nome del package, nell’esempio quello di default.

XStream usa il meccanimo delle Annotations per definire gli alias, rendendo così la definizione decisamente più pratica. Vediamo un esempio di codice che non definisce alias:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package it.devme.music;
 
public class Police {
    private String songTitle;
    public Police(String songTitle) {
        this.songTitle = songTitle;
    }
}
 
package it.devme.music;
public class JukeBox {
    public static void main(String[] args) {
        XStream stream = new XStream();
	Police song = new Police("Message in a bottle");
	System.out.println(stream.toXML(msg));
    }
}

L’esecuzione del codice produce il seguente XML:

1
2
3

    <it.devme.music.Police>
        <songTitle>Message in a bottle</songTitle>
    </it.devme.music.Police>

Come si può notare, senza l’utilizzo degli alias la serializzazione in XML non è coincisa, in particolare il nome della classe Persona eredita l’intero percorso del suo package di appartenenza. Definiamo ora gli alias usando le Annotations:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

package it.devme.music;
 
@XStreamAlias("police-songography")
public class Police {
    @XStreamAlias("song")
    private String songTitle;
    public Police(String songTitle) {
        this.songTitle = songTitle;
    }
}
 
package it.devme.music;
public class JukeBox {
    public static void main(String[] args) {
        XStream stream = new XStream();
	Police song = new Police("Message in a bottle");
	System.out.println(stream.toXML(msg));
    }
}

L’esecuzione del codice produce il seguente XML:

1
2
3

    <police-songography>
        <song>Message in a bottle</song>
    </police-songography>

Notate ora come il file XML è più chiaro e come il nome dei tag non dipende strettamente dai nomi delle classi e/o delle variabili membro, ma dagli alias definiti all’interno della classe stessa.

Come ultima cosa volevo soffermarmi su un’altra caratteristica di questa libreria, i Converter. Questo meccanismo da la possibilità di poter gestire in fase di serializzazione/deserializzazione l’esatta elaborazione che deve essere svolta in modo tale da avere una corretta esecuzione delle procedure. Per poter scrivere il proprio Converter è necessario implementare l’interfaccia Converter ed implementare i metodi proposti:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package it.devme.music;
public class PoliceConverter implements Converter {
    public boolean canConvert(Class clazz) {
        return false;
    }
 
    public void marshal(Object value, HierarchicalStreamWriter writer,
                        MarshallingContext context) {
        }
 
    public Object unmarshal(HierarchicalStreamReader reader,
                        UnmarshallingContext context) {
        return null;
    }
}

Il metodo canConvert verifica l’applicabilità del converter rispetto alla classe che si desidera pre/post elaborare. Il metodo marshal è una pre elaborazione, mentre unmurshal è una post elaborazione. I casi d’uso di un Converter variano dai più semplici, in cui si applica una trasformazione al tipo di dato che dovrà essere serializzato (si pensi ad esempio ad una data in formato millisecondi da trasformare in gg/mm/aaaa), ai più complessi in cui è necessario elaborare un nodo complesso contenente sottoalberi, ovviamente in entrambe le operazioni di serializzazione/deserializzazione. Vi rimando al tutorial sui Converter per gli esempi del caso.

See U on next post, enjoy !

Singleton pattern: quando e come usarlo.

Traendo ispirazione su un post trovato per la rete, ho deciso di scrivere un piccolo, ma proprio piccolo post, sul pattern Singleton, molto usato durante le sessioni di programmazione per risolvere una certa classe di problemi comuni. Definiamo un singleton come:
una classe per cui esiste una sola istanza nell’applicazione, e per la quale viene fornito un’unico punto globale di accesso.
Vediamo un possibile modo di implementare il singleton:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class DevMeSingleton {
    /* class instance */
    private static DevMeSingleton instance;
    /* Costruttore privato della classe */
    private DevMeSingleton() {}
 
    /* Metodo che permette di ottenere l'istanza della classe */
    public static DevMeSingleton getInstance() {
        if (instance==null) {
            instance = new DevMeSingleton();
        }
        return instance;
    }
}

1. Semplice implementazione singleton pattern

L’implementazione di cui sopra, può causare problemi di performance nel contesto di un applicazione multithreading. E’ possibili che 2 thread ottengano in contemporanea 2 istanze della classe singleton, violando così un presupposto fondamentale della definizione. Per far sì che il comportamento non sia critico in un contesto del genere, si consideri l’utilizzo della tecnica: double-checked locking. 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class DevMeSingleton {
        /* class instance */
        private volatile static DevMeSingleton instance;
 
        /* Costruttore privato della classe */
        private DevMeSingleton() {}
 
        /* Metodo che permette di ottenere l'istanza della classe */
        public static DevMeSingleton getInstance() {
            if (instance==null) {
                synchronized(DevMeSingleton.class) {
                    if (instance==null) {
                        instance = new DevMeSingleton();
                    }
                }
            }
        return instance;
    }
}

2. Tecnica double-checked locking

Questa tecnica purtroppo non funziona con la JVM 1.4 a causa della defizione della variabile volatile, la quale non era stata ancora implementata. Per ovviare a questo problema, vediamo l’implementazione successiva. 

1
2
3
4
5
6
7
8
9
10
11
12
13

public class DevMeSingleton {
 
        /* class instance */
        private static DevMeSingleton instance = new DevMeSingleton();
 
        /* Costruttore privato della classe */
        private DevMeSingleton() {}
 
        /* Metodo che permette di ottenere l'istanza della classe */
        public static DevMeSingleton getInstance() {
            return instance;
        }
}

3. Creazione efficiente dell’istanza di una classe Singleton

L’implementazione di cui sopra, garantisce la creazione efficiente dell’istanza della classe singleton, piuttosto di una creazione cosiddetta lazy (pigra). Il singleton viene creato all’atto dell’invocazione della classe, in quel momento vengono istanziate tutte le varibili static, tra cui anche l’istanza del singleton. Spero che possa essere utile. A presto.

Axis howTo

Salve, ultimamente ho avuto a che fare con lo sviluppo di web services, tecnologia molto interessante che permette di far dialogare sistemi sviluppati con diverse tecnologie…si pensi ad esempio, ad un back-end sviluppato in python e il front-end sviluppato in Java che effettua interrogazioni. Attraverso l’uso dei web services, è possibile realizzare una tale l’interazione. Sostanzialmente un web service, è un servizio lato server, che può essere invocato passando all’occorrenza dei parametri, e che può restituire un risultato. In Java, un modo abbastanza diffuso, è quello di utilizzare Axis, una libreria che permette lo sviluppo di web service, molto potente.Possono essere sviluppati utilizzando due modalità: contract-first, contract-last. La prima non prevede alcuna definizione del servizio, basta cioè sviluppare la classe che implementa il servizio ed esporla verso l’esterno. La seconda modalità, contract-last, prevede invece la scrittura di un file xml, chiamato web-service deployment descriptor (WSDD), che elenca al suo interno quali metodi della classe saranno esposti all’esterno, eventuale autenticazione per l’utilizzo del servizio ed eventuale mapping di tipi complessi. Una semplice richiesta per utilizzare un servizio consiste nella scrittura di un client che, invoca opportunamente un web service attraverso l’utilizzo delle librerie di Axis. Il compito delle librerie è quello di tradurre la richiesta in stream xml, il quale viene inviato al server utilizzando il protocollo HTTP come protocollo di trasporto. Lato server, lo stream xml viene ricevuto, tradotto e quindi eseguito il metodo. Dall’altra parte, l’eventuale risultato viene tradotto anch’esso in flusso XML e quindi inviato al client, che si occuperà di tradurlo. Vediamo di seguito come configurare Axis per fare in modo di eseguire in semplice web service, sia lato client che lato server. Bisogna innanzitutto scaricare axis da qui. Dopo aver decompresso il pacchetto, è possibile testare le applicazioni di default che sono contenuto all’interno, copiando il contenuto della directory webapps all’interno della directory webapps del vostro servlet-container preferito, nell’esempio consideriamo che sia tomcat, versione 5.5.25. Quindi collegandoci all’indirizzo http://localhost:8080/axis, potrete vedere in cosa consiste l’applicazione, che mostra anche un esempio di file WSDD. Per poter testare un web service invocandolo, è necessario perfezionare qualche dettaglio dell’installazione. Definiamo alcune variabili d’ambiente che memorizzano i path di installazione delle librerie di axis:

1
2
3
4
5
6

set AXIS_HOME=/opt/axis
set AXIS_LIB=$AXIS_HOME/lib
set AXISCLASSPATH=$AXIS_LIB/axis.jar:$AXIS_LIB/commons-discovery.jar:
$AXIS_LIB/commons-logging.jar:$AXIS_LIB/jaxrpc.jar:$AXIS_LIB/saaj.jar:
$AXIS_LIB/log4j-1.2.8.jar:$AXIS_LIB/xml-apis.jar:$AXIS_LIB/xercesImpl.jar
export AXIS_HOME; export AXIS_LIB; export AXISCLASSPATH

E’ chiaro dall’esempio che il sistema operativo di riferimento per i test è linux. Quindi definiamo le variabili d’ambiente fissandole sui valori dei path di axis, considerando di averle installate in /opt/axis. Fatto ciò, selezioniamo un esempio, dalla directory samples di axis, axis/samples/stock e prendiamo il descrittore del servizio per effettuare il deploy. Per effettuare il deploy sarà necessario invocare il web service Administrator integrato in Axis che realizza il deploy in Axis-engine del descrittore selezionato. Supponendo di posizionarci nella directory dove riesiede il file deploy.wsdd, l’invocazione per effettuare il deploy è la seguente:

1
2

java -cp $AXISCLASSPATH org.apache.axis.client.AdminClient
-lhttp://localhost:8080/axis/services/AdminService deploy.wsdd

se ottenete un errore del tipo ClassNotFoundException, probabilmente avete dei problemi con la definizione delle varibili d’ambiente per axis, quindi verificare che sia corretta. Se siete stati spinti dalla curiosità, probabilmente avrete dato un occhiata al contenuto del file wsdd, e quindi avrete intuito che viene richiesta l’autenticazione per accedere al servizio. Volendo testare a questo punto il web service, quello che dobbiamo fare è:

1
2

java -cp $AXISCLASSPATH samples.stock.GetQuote
-lhttp://localhost:8080/axis/servlet/AxisServlet -uuser1 -wpass1 XXX

che invoca il servizio chiamato GetQuote passando come parametro XXX in aggiunta a user e password. Il risultato che otteniamo, se tutto procede correttamente, è: "55.25". Quindi abbiamo visto come fare il deploy di un web service all’interno dell’engine di axis e come invocarlo da linea di comando. Vediamo ora, più o meno sinteticamente, come creare rispettivamente il lato server e quello client di un web service. Il nostro ambiente di sviluppo sarà eclipse J2EE, all’interno del quale cominceremo con lo sviluppare una "Dynamic web application" chiamata devmeWS. La nostra applicazione sarà veramente semplice ed elencherà i post presenti sul sito. Definiamo la struttura del nostro value object, ovvero del bean che memorizzerà le informazioni sui post, molto semplicemente si ha:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class PostVO implements Serializable {
    private String titolo;
    private String descrizione;
    public PostVO() {}
 
    public int getTitolo() {
        return titolo;
    }
 
    public void setTitolo(String titolo) {
        this.titolo = titolo;
    }
 
    public int getDescrizione() {
        return descrizionr;
    }
 
    public void setDescrizione(String descrizione) {
        this.descrizione = descrizione;
    }
}

Il nostro VO ha 2 campi che sono il titolo e la descrizione del post, con i relativi getter e setter. La logica banale del nostro web service è la seguente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public class CatalogoWS {
 
    public CatalogoWS() { }
 
    public Vector getListaPost() {
        Vector lista = new Vector();
        // post1
        PostVO post1 = new PostVO();
        post1.setTitolo("Spring Web Flow, DWR: perfect combination !");
        post1.setDescrizione("L'integrazione delle tecnologie più diffuse....");
        // post2
        PostVO post2 = new PostVO();
        post2.setTitolo("Il grosso grasso JAR....");
        post2.setDescrizione("Come si esegue un ricco jar");
        return lista;
     }

// web service descriptor deployment
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
            xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
    <service name="urn:catalogoWS" provider="java:RPC" style="rpc" use="  encoded">
        <parameter name="className" value="it.devme.ws.CatalogoWS"/>
        <parameter name="allowedMethods" value="getListaPost"/>
        <parameter name="scope" value="Session"/>
        <beanMapping qname="myNS:PostVO" xmlns:myNS="urn:catalogoWS"  languageSpecificType="java:it.devme.vo.ProdottoVO"/>
    </service>
</deployment>

Sostanzialmente il web service, costruisce una lista di oggetto Post e la restituisce al client che ne visualizzerà il contenuto. Dobbiamo costruire a mano il nostro wsdd, anche questo molto banale che definisce il nostro web service, il riferimento alla classe che lo implementa ed il/i metodi che sono esposti verso l’esterno. Osserviamo che abbiamo definito anche un nostro tipo di dato custom, PostVO mappato su un namespace di esempio chiamato myNS. La definizione di tale tipo permette di poter serializzare/deserializzare il risultato fornito dal server o la richiesta inviata dal client, in xml, in modo tale da poter essere letto o scritto all’occorrenza. Più semplicemente, quando un web service invia un risultato, se questi è di un qualche tipo primitivo, viene serializzato in un tag xml che lo contiene. Se il risultato è di tipo più complesso, ad esempio PostVO, dovrà anch’esso essere serializzato in una qualche forma tale per cui sarà poi possibile la de-serializzazione client-side. Queste 2 operazioni, serializzazione/deserializzazione, sono possibili grazie al mapping nel file descrittore dei tipi predefiniti. Il client si basa anch’esso sulle librerie di axis, che permettono di invocare il metodo remoto e manipolare il risultato.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public class Client {
 
    public static void main(String[] args) {
        try {
            Call call = (Call) new Service().createCall();
            call.setTargetEndpointAddress(new URL("http://localhost:8080/productWS/services"));
            QName qnameProd = new QName("urn:catalogoWS", "PostVO");
            Class classeProd = PostVO.class;
            call.registerTypeMapping(classeProd, qnameProd, BeanSerializerFactory.class,
            //richiamo il metodo getListaPost
            call.setOperationName(new QName("urn:catalogoWS", "getListaPost"));
            Object rispostaWS = call.invoke(new Object[]{});
            Vector lista = (Vector) rispostaWS;
            System.out.println("Il catalogo comprende:");
            Iterator iter = lista.iterator();
            PostVO item = null;
            while (iter.hasNext()) {
                item = (PostVO) iter.next();
                visualizza(item);
            }
        } catch (Exception ex) {
            System.out.println("Si è verificata l'eccezione: " + ex.toString());
        }
    }
}

Il client è un’applicazione classe Java semplice che usa le librerie di axis per effettuare l’invocazione del metodo remoto. Viene fissato il tipo di dato custom e mappato sulla relativa classe che lo implementa, che ovviamente, è necessaria anche sul lato client. Viene impostato il nome del metodo da invocare, come nome dell’operazione da svolgere ed infine viene effettuata l’invocazione, la quale se non ci sono errori, restituisce un vettore di oggetti Post che vengono visualizzati all’interno del ciclo seguente la chiamata. Da osservare una cosa molto importante, e cioè che affinché tutto funzioni, sarà necessario installare il servizio creato, all’interno di axis engine che provvederà quindi a renderlo disponibile.

1
2

java -cp $AXISCLASSPATH org.apache.axis.client.AdminClient
-lhttp://localhost:8080/axis/services/AdminService deploy.wsdd

Spero di essermi ricordato tutto correttamente e senza errori, era da un pò di tempo che volevo pubblicare un post del genere, ma solo oggi sono riuscito a ritagliare in tempo per farlo. Sono andato a mente spero di non aver ricordato male. Qui trovate l’esempio di cui sopra, client e server implementati. Buone vacanze.

Spring Web Flow, DWR: perfect combination !

Dopo un lungo letargo arieccomi qui a parlare di questioni informatiche che trovo prima di tutto molto divertenti (vi chiederete: che tipo è questo?) e dopo molto interessanti. Trovandomi ultimamente occupato allo sviluppo di un applicazione web di cui spero sentirete parlare molto presto, ho provato dapprima e poi ormai adottato la tecnologia messa a disposizione da Spring Web Flow, un framework basato su Spring che permette di definire dei flussi di navigazione per un applicazione web in modo semplice, chiaro e potente…..molto potente. Tralasciamo qui la discussione dei dettagli della tecnologia, per descrivere quello che in sostanza è un integrazione tra SWF, DWR Direct Web Remoting, un framework che aggiunge il supporto AJAX alle nostre applicazioni. Come dicevo, non starò a dettagliare ciò che vogliono dire i file di configurazione, il significato, etc etc, dando tutto per scontato….in futuro se risciro magari, pubblicherò qualche tutorial su Spring framework e spring web flow, anche se in rete si trova di tutto. Ciò detto….let’s start! Occurre naturalmente scaricare la libreria: DWR. Dopo di che si procede con ordine. Sinteticamente, ricordiamo che DWR permette di richiamare attraverso una call-back, dei metodi remoti esposti server side. I risultati restituiti dalla chiamata ai metodi, che possono essere di tipo semplice (int, String, boolean) o complesso come Array di oggetti o di tipi semplice. I risultati vengono "trasformati" e forniti come varibili javascript (array, stringhe o quant’altro) le quali possono essere usati poi localmente. Editiamo il file web.xml aggiungenfo le seguenti linee:

1
2
3
4
5
6
7
8
9
10
11
12

<servlet>
    <servlet-name>dwr</servlet-name>
    <servlet-class>org.directwebremoting.spring.DwrSpringServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>true</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>dwr</servlet-name>
    <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

le quali inizializzano la servlet che permetterà il riconoscimento delle chiamate verso gli script javascript per realizzare l’interazione AJAX. L’integrazione di DWR 2.0 con Spring 2.5 è molto più light rispetto alla versione precedente. Sostanzialmente basta aggiungere il namespace di dwr in testa al file di configurazione globale di spring, definire il controller e qualche mapping di URL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
          xsi:schemaLocation="http://www.springframework.org/schema/beans
          http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
          http://www.directwebremoting.org/schema/spring-dwr
         http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd">
 
    <dwr:controller id="dwrController" debug="true" />
    <bean id="urlMapping" 
             class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="mappings">
            <props>
                <!-- DWR configuration -->
                <prop key="/dwr/**/*.*">dwrController</prop>
                <prop key="/dwr/**/*">dwrController</prop>
                <prop key="/dwr">dwrController</prop>
                <prop key="*.html">dwrController</prop>
            </props>
        </property>
        <property name="alwaysUseFullPath" value="true"/>
    </bean>
</beans>

Successivamente ci rimane da dichiarare il metodo remoto che si vuole esporre e la eventuale classe che si desidera gestire dal client con javascript. Il tutto si fa dal file xml, che per chiarezza scrivo sempre a parte e poi lo includo in web.xml come facente parte della configurazione.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

File: dwr.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:dwr="http://www.directwebremoting.org/schema/spring-dwr"
          xsi:schemaLocation="http://www.springframework.org/schema/beans
          http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
          http://www.directwebremoting.org/schema/spring-dwr
          http://www.directwebremoting.org/schema/spring-dwr-2.0.xsd">
    <bean id="dwrexposure" class="it.devme.dwr.exposure.DWRExposure">
        <dwr:remote javascript="DWR">
            <dwr:include method="retriveProductCompanyList" />
        </dwr:remote>
        <property name="baseManager"><ref bean="baseManager"/></property>
    </bean>
    <dwr:configuration>
        <dwr:convert type="bean" class="it.devme.dwr.exposure.ProductsVO" />
    </dwr:configuration>
</beans>

Praticamente abbiamo fatto, DWRExposureè la classe che contiene il metodo retriveProductCompanyList che intendiamo esporre, che restituisce un array di oggetti ProductsVO i quali vengono convertiti e resi utilizzabili da locale da DWR, con il tag dwr:convert che indichiamo. L’oggetto ProductsVO è un semplicissimo Java Bean contenente 2 campi che sono l’id del prodotto e la sua descrizione. Da client side, includiamo i seguenti script:

1
2
3

<script type="text/javascript" src="<c:url value="dwr/interface/DWR.js"/>"></script>
<script type="text/javascript" src="<c:url value="dwr/engine.js"/>"></script>
<script type="text/javascript" src="<c:url value="dwr/util.js"/>"></script>

Il primo viene creato da DWR e contiene la logica che permette l’invocazione del metodo remoto e il recupero del risultato. Le altre 2 inclusioni permettono l’utilizzo di alcune funzioni di utilità molto comode. Vediamo ora come fare a usare il tutto. Use case: 2 select, uno che contiene una lista di utenti. L’altro conterrà la lista dei prodotti associati all’utente. La selezione del primo, fa scattare l’invocazione del metodo remoto che riempie il secondo select con i dati dei prodotti associati all’utente selezionato:

1
2
3
4
5
6
7
8

<select name="user_id" id="user_id" onchange="loadProduct();">
    <option value="0">Scegli</option>
    <option value="1">Utente1</option>
    <option value="2">Utente2</option>
</select>
<select name="product_id" id="product_id" >
    <option value="0">Scegli</option>
</select>

Quindi selezionando l’utente dalla lista, verrà richiamato il codice javascript che andremo a scrivere, che richiamerà il metodo remoto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

/** Call Remote method and
load products data */
function loadProduct() {
    var user_id = DWRUtil.getValue("user_id");
    if (user_id>0) {
        DWR.retriveProductsList(user_id, gotProducts);
    } else {
        dwr.util.removeAllOptions("product_id");
        dwr.util.addOptions("product_id", [ { name:'Scegli..', id:'0' } ], "id", "name");
        document.campaign.product_id.disabled=true;
    }
}
function gotProducts(products) {
    dwr.util.addOptions("product_id", products, "idproduct", "name");
    document.campaign.product_id.disabled=false;
}

La prima funzione loadProduct() richiamerà il metodo remoto, selezionando l’utente dall’elemento select attraverso la funzione di utilità DWRUtil.getValue("user_id"). Il metodo richiamato restituirà il risultato alla funziona gotProducts(products) fornendolo come parametro. L’array di oggetti a questo punto, conterrà le informazioni sui prodotti associati all’utente, e può essere assegnato al select dei prodotti attraverso l’altra funzione di utilità dwr.util.addOptions("product_id", products, "idproduct", "name"). E il gioco è fatto…con una semplicità incredibile, senza requirements mostruoso o complessi si aggiunge il supporto ad AJAX alla nostra applicazione Java, in particolare Spring. Con queste informazioni in mani ci si può sbizzarire creando il proprio personale componente AJAX. Nel prossimo articolo vedremo come integrare il supporto per JCaptcha per rendere più sicure le nostre applicazione. Alla prossima.

Array & Java Reflection

In questo periodo si lavora abbastanza…si programma come al solito usando Java…il mio linguaggio di programmazione di riferimento. Ho avuto a che fare con la riflessione, approcci comuni quali richiamare dei metodi su oggetti, prelevarne i valori delle variabili membro, etc…il tutto ovviamente fatto a run-time. Ho letto un piccolo hint su come recuperare l’istanza di una classe di un Array usando la riflessione in Java. Ricordiamo come si recupera l’istanza di una classe usando la riflessione:

• Class.forName("it.devme.MYClass"), per ottenere l’istanza dal nome della classe
• MYClass.class, per ottenere l’istanza dal tipo
• Integer.TYPE, per ottenre l’istanza da qualunque tipo primitivo

E nel caso di un array ??
Come suggerito nell’articolo, un array è anch’esso un oggetto e quindi possiede una classe, ma con i metodi suggeriti sopra non è possibile ottenerne l’istanza a runtime. Un modo per fare ciò è il seguente:

• Class.forName("[C"), per un array di caratteri. Si specifica come nome [C che corrisponde al nome della rappresentazione data dal linguaggio agli array di caratteri. Se vi capita di fare debug con un IDE a caso, ad esempio eclipse, vi accorgerete che la rappresentazione di un oggetto array di caratteri data dal linguaggio Java inizia con [C
• Class.forName("[Ljava.lang.String;"), per un array di stringhe.

L'articolo si conclude con un suggerimento dato da un guru di Java, Tim Eck, che suggerisce di usare semplicemente l'istruzione:

char[].class

per ottenere l’istanza di una classe di array di caratteri.