Chi lavora con me sa che già da qualche mese sto provando un framework per l'interfaccia utente chiamato ZK.
In mezzo a questa guerra "tutti contro tutti" tra i vari framework per l'interfaccia utente questo post potrebbe essere giudicato poco interessante.
In effetti tra i vari JavaFX, Google Web Toolkit, Flex2, JSF, un framework come ZK potrebbe sembrare qualcosa di decisamente minore e destinato a soccombere, ma dopo averlo provato un po' vi giuro che ha delle potenzialità enormi che gli altri che ho provato non hanno.
Cominciamo con il dire che è un tool per lo sviluppo di RIA (Rich Internet Applications) e non di interfacce Web classiche come Struts o Spring MVC. Dunque già ci poniamo un gradino avanti a numerosi concorrenti. Ma ne rimangono di decisamente agguerriti, come quelli che ho citato prima.
La cosa principale con cui mi sono scontrato provando gli altri tool per lo sviluppo di RIA è la comunicazione con il server! Di solito ci troviamo di fronte a strumenti che ci mettono a disposizione interfacce di comunicazione di medio livello come un client HTTP oppure meccanismi di comunicazione "trasparenti" per lo più non Object Oriented come la possibilità di invocare metodi statici o di oggetti singleton che si trovano sul server.
Ma per chi, come me, è convinto della bontà di avere un modello Object Oriented questo non è sufficiente. Ci si trova in balia di un modello che vive metà sul client e metà sul server e tenere sincronizzate le due metà è un vero incubo! Cerchiamo di chiarire questo fatto con un esempio.
Supponiamo di sviluppare un modello ad oggetti di un software bancario. Avremo a che fare con oggetti quali: Cliente, ContoCorrente, ecc. Per incapsulare bene l'apertura di un nuovo conto corrente potremmo mettere nella classe Cliente un metodo apriNuovoConto(), che si preoccuperà di effettuare tutte le operazioni necessarie (che potrebbero anche essere molte e molto complesse). Volendo lavorare correttamente con questo modello dovremmo:
Davanti a questa e altre difficoltà si tende a ricadere verso il "solito" modello procedurale in cui ci sono delle funzioni che manipolano dei finti oggetti che in realtà sono solamente dei record. E' facile far viaggiare questi record su e giù tra client e server ma ogni volta che abbiamo bisogno di qualcosa di leggermente diverso dobbiamo ricominciare da capo: un nuovo tipo di oggetto (stupido) e un nuovo insieme di funzioni per manipolare questi nuovi oggetti. Possibile che non ci sia qualcosa che ci permetta di ottenere un software un po' più manutenibile?
Qui entra in gioco ZK! Non sarà la panacea di tutti i mali ma di certo per certe categorie di applicazioni ci permette di lavorare in maniera completamente Object Oriented senza dover impazzire.
Il modello proposto da ZK è semplice: ogni volta che l'utente effettua un'operazione che genera un evento viene effettuata una chiamata al server, in risposta a questa chiamata il server esegue una porzione di codice (il gestore dell'evento) che può modificare le caratteristiche dell'interfaccia utente (aprire nuove finestre, modificare il contenuto dei campi, ecc.). Al termine il client riceve tutte queste modifiche e ridisegna di conseguenza l'interfaccia utente.
Nel nostro esempio della banca l'oggetto Cliente non deve essere trasferito sul client. Sarà direttamente il server a tenere questo oggetto ,a chiamarne i metodi e a visualizzarne le informazioni all'interno dei campi dell'interfaccia utente.
Ovviamente, come dice anche il manuale di ZK, non stiamo sfruttando affatto la potenza di calcolo del client ma quasi esclusivamente quella del server. Per questo ZK non è adatto ad applicazioni estremamente pesanti o con un carico di utenti molto elevato, ma per il tipo di applicazioni che ho sviluppato fino ad oggi (applicazioni aziendali con alcune centinaia di utenti), mi sembra più che adeguato.
In più esiste una versione di ZK per J2ME, sempre con la stessa filosofia. Una Midlet che gira sul cellulare si preoccupa di fare le veci del browser web.
Sto provando a scrivere un'applicazione demo utilizzando ZK. Nei prossimi post vi descriverò l'applicazione e la sua struttura per chiarire meglio i concetti che ho esposto oggi in maniera un po' troppo rapida.
A presto
In mezzo a questa guerra "tutti contro tutti" tra i vari framework per l'interfaccia utente questo post potrebbe essere giudicato poco interessante.
In effetti tra i vari JavaFX, Google Web Toolkit, Flex2, JSF, un framework come ZK potrebbe sembrare qualcosa di decisamente minore e destinato a soccombere, ma dopo averlo provato un po' vi giuro che ha delle potenzialità enormi che gli altri che ho provato non hanno.
Cominciamo con il dire che è un tool per lo sviluppo di RIA (Rich Internet Applications) e non di interfacce Web classiche come Struts o Spring MVC. Dunque già ci poniamo un gradino avanti a numerosi concorrenti. Ma ne rimangono di decisamente agguerriti, come quelli che ho citato prima.
La cosa principale con cui mi sono scontrato provando gli altri tool per lo sviluppo di RIA è la comunicazione con il server! Di solito ci troviamo di fronte a strumenti che ci mettono a disposizione interfacce di comunicazione di medio livello come un client HTTP oppure meccanismi di comunicazione "trasparenti" per lo più non Object Oriented come la possibilità di invocare metodi statici o di oggetti singleton che si trovano sul server.
Ma per chi, come me, è convinto della bontà di avere un modello Object Oriented questo non è sufficiente. Ci si trova in balia di un modello che vive metà sul client e metà sul server e tenere sincronizzate le due metà è un vero incubo! Cerchiamo di chiarire questo fatto con un esempio.
Supponiamo di sviluppare un modello ad oggetti di un software bancario. Avremo a che fare con oggetti quali: Cliente, ContoCorrente, ecc. Per incapsulare bene l'apertura di un nuovo conto corrente potremmo mettere nella classe Cliente un metodo apriNuovoConto(), che si preoccuperà di effettuare tutte le operazioni necessarie (che potrebbero anche essere molte e molto complesse). Volendo lavorare correttamente con questo modello dovremmo:
- Ricostruire dal database l'oggetto Cliente per il quale si vuole aprire un nuovo conto. Supponiamo per semplicità dell'esempio che la persona sia già cliente della banca
- Mostrare questo oggetto sullo schermo
- Attendere che l'utente prema il pulsante "Apri Nuovo Conto" (o qualcosa di simile)
- Chiamare il metodo apriNuovoConto() dell'oggetto
Davanti a questa e altre difficoltà si tende a ricadere verso il "solito" modello procedurale in cui ci sono delle funzioni che manipolano dei finti oggetti che in realtà sono solamente dei record. E' facile far viaggiare questi record su e giù tra client e server ma ogni volta che abbiamo bisogno di qualcosa di leggermente diverso dobbiamo ricominciare da capo: un nuovo tipo di oggetto (stupido) e un nuovo insieme di funzioni per manipolare questi nuovi oggetti. Possibile che non ci sia qualcosa che ci permetta di ottenere un software un po' più manutenibile?
Qui entra in gioco ZK! Non sarà la panacea di tutti i mali ma di certo per certe categorie di applicazioni ci permette di lavorare in maniera completamente Object Oriented senza dover impazzire.
Il modello proposto da ZK è semplice: ogni volta che l'utente effettua un'operazione che genera un evento viene effettuata una chiamata al server, in risposta a questa chiamata il server esegue una porzione di codice (il gestore dell'evento) che può modificare le caratteristiche dell'interfaccia utente (aprire nuove finestre, modificare il contenuto dei campi, ecc.). Al termine il client riceve tutte queste modifiche e ridisegna di conseguenza l'interfaccia utente.
Nel nostro esempio della banca l'oggetto Cliente non deve essere trasferito sul client. Sarà direttamente il server a tenere questo oggetto ,a chiamarne i metodi e a visualizzarne le informazioni all'interno dei campi dell'interfaccia utente.
Ovviamente, come dice anche il manuale di ZK, non stiamo sfruttando affatto la potenza di calcolo del client ma quasi esclusivamente quella del server. Per questo ZK non è adatto ad applicazioni estremamente pesanti o con un carico di utenti molto elevato, ma per il tipo di applicazioni che ho sviluppato fino ad oggi (applicazioni aziendali con alcune centinaia di utenti), mi sembra più che adeguato.
In più esiste una versione di ZK per J2ME, sempre con la stessa filosofia. Una Midlet che gira sul cellulare si preoccupa di fare le veci del browser web.
Sto provando a scrivere un'applicazione demo utilizzando ZK. Nei prossimi post vi descriverò l'applicazione e la sua struttura per chiarire meglio i concetti che ho esposto oggi in maniera un po' troppo rapida.
A presto
