Il documento analizza l'evoluzione dalle architetture web 1.0 a quelle web 2.0, evidenziando i difetti storici di HTML su HTTP e l'importanza di AJAX nel disaccoppiare presentazione e scambio di dati. Viene discusso il framework SmartClient, che utilizza un'architettura client-side MVC e offre un sistema di data binding efficace, suggerendo varie opzioni di licensing. Infine, si forniscono consigli pratici sulla documentazione e sull'utilizzo della SDK di SmartClient.

1. Claudio Bosticco
Claudio.bosticco@gmail.com

2. WEB 1.0
 Ad ogni interazione, il browser invia una richiesta ad una
specifica risorsa (URL) con dei parametri associati alla richiesta.
 Il web server risponde con l’intera pagina: HTML+CSS+Javascript
 La pagina contiene sia il codice necessario alla sua
renderizzazione, sia i dati.
 È una caratteristica “storica” di html over http
Inoltre il client è più o meno stupido:
business logic e presentazione sono interamente in mano al server

3. WEB 1.0: flaws
 I dati non sono trattati come “first class objects”
(non hanno né tipo, né struttura, né vincoli).
 Presentation Flow e Data Interchange, che sono ortogonali,
risultano strettamente accoppiati, uno non può avvenire senza
che avvenga l’altro (Ajax, alternativo a hmtl over http, li
disaccoppia).
 Non supporta server push.
Esiste un web framework server-side che non abbia tali difetti?

4. RIA (web 2.0)
 Al primo accesso alla web application, viene scaricato il
codice client della webapp stessa.
 Il browser è il contenitore dell’applicazione.
 Da questo punto, se il client ha bisogno di dati che non ha, o
se deve aggiornare/aggiungere dati, invia una richiesta al
server.
 Il server invia/aggiorna i dati (quelli che l’utente è
autorizzato a vedere/aggiornare – solo il server può
garantire la sicurezza).
 La presentazione dei dati all’utente viene gestita lato client.

5. RIA Architecture
 Un paper illuminante: Life above the Service Tier:
“Had we but invested in clientside JavaScript half the resources we invested in
serverside Java, we could have had AJAX far earlier (and we could have
avoided wasting our time on fifty different Front Controller frameworks).”
 MVC sul client: presentation flow tramite “javascript magic”:
Single Page Application.
 Ajax per disaccoppiare presentation flow e data interchange
 XML o JSON restituiscono dignità ai dati

6. Life Above the Service Tier

7. SmartClientTM RIA Framework
 Since 2001, architettura “client side MVC”, “Ajax” da prima che
esistesse l’acronimo.
 LGPL da 11/2007 (parte client).
 Perfettamente in linea con l’architettura SOFEA.
 Componenti client molto ricchi.
 Ampia compatibilità coi browser (IE6 ancora compatibile con la
release 10 uscita a fine 2014), anche sul mobile.
 Sistema di databinding client/server: i “business objects” sono
modellati nelle DataSource che sono condivise tra client e
server.
 Tramite le DataSource stesse è disponibile un motore di
persistenza molto efficace (oppure connettori per
JPA/Hibernate).

8. SmartClient DataSources
 Il mio consiglio è, se possibile, di usare le SQLDataSource,
possibilmente con licenza Power (ovviamente a patto di
usare un db relazionale).
 La velocità di sviluppo che si ottiene rispetto ad altri
framework e anche rispetto ad altri ORM (Hibernate,
myBatis…) vale la spesa.
 Ovviamente richiede maggiori conoscenze del framework
rispetto ad utilizzare “solo” la versione LGPL ad es.

9. Licensing
 LGPL -> solo parte client (esclusi alcuni moduli)
A costi crescenti:
 Pro
 Power
 Enterprise
Moduli a parte:
 RealTime Messaging (AKA server push)
 Analytics (OLAP/Datacube)

10. Exploring SmartClient
 Il pacchetto contiene una SDK con un tomcat e un HSQLDB
embedded con documentazione ed esempi ricercabili ed
editabili.
 La documentazione è molto ben fatta, ma per i principianti è un
po’ difficile visualizzare la “big picture” viste le dimensioni del
framework.
 È consigliabile iniziare dalla “quick start guide”, per poi
approfondire le tematiche nella cartella “Concepts” della
Reference (e nella cartella “Java Server Reference” se si utilizza la
parte server).
 Fondamentale “smanettare” sugli esempi ed iniziare da subito ad
utilizzare la “developer console”.

11. Un esempio dalla SDK

12. Coding in SmartClient
 In SmartClient, l’oggetto ClassFactory è alla base di un
meccanismo di vera ereditarietà per oggetti Javascript.
 Questo significa che con gli oggetti SmartClient è possibile
invocare metodi delle superclassi, avere attributi e metodi
di istanza ma anche statici.
 ClassFactory è un sigleton che viene utilizzato
principalmente per definire nuove classi:
 ClassFactory.defineClass("MyClass", “MySuperClass");
 Per creare un’istanza:
 ClassFactory.newInstance(“MyClass”);

13. Coding – syntactic sugar
isc.defineClass("MyListGrid", "ListGrid").addProperties({
headerHeight: 40, // cambia default per listGrid.headerHeight
// override listGrid.recordClick
recordClick: function (viewer, record) {
isc.say(record.description); // invece di alert()
}
})
isc.MyListGrid.create({ // crea un’instanza della nuova classe
ID: “fooGrid” // variabile globale
});
fooGrid.fetchData(
{STATE: “ACCEPTED”}, // criteria
function(dsResponse, data, dsRequest){ // callback
isc.logEchoAll(data);
}
})
Il prefisso “isc.” è necessario se si usa il “Portal mode”