Dimitri De Franciscis

Consulente software freelance

Primary links

  • Homepage
  • Chi sono
  • Pubblicazioni
  • Curriculum Vitae
  • Libri e guide
  • Fotografia
  • Pittura
  • Contattami
Home Blog dimitri's blog

Ajax o non Ajax?

Submitted by dimitri on Ven, 14/11/2008 - 10:58
  • Informatica
  • ajax
  • appfuse
  • dojo
  • framework
  • java
  • javascript
  • mvc
  • open source
  • spring
  • wicket

Il dilemma della lavandaia

Da un po’ di tempo sto dedicando parte del mio tempo libero ad un progettino pesonale, il quale in un futuro non troppo immediato potrebbe diventare open source. Mi sono rivolto allora ad alcuni ex-colleghi molto validi (che ringrazio pubblicamente), i quali mi hanno fornito pareri diversi e decisamente illuminanti. In ogni caso tutti sono riusciti a spiegarmi perché scegliere una strada piuttosto che un’altra. Non è poco.

Quella che segue è la discussione nata da una mail di richiesta aiuto che ho inviato sull’argomento.

Indice degli interventi

  • (Dimitri) Messaggio originale
    • Filippo
    • Massimiliano
    • Luca
    • Pietro
    • Marco
  • Conclusioni

^ top

(Dimitri) Messaggio originale

Ciao hippy dell’informatica,
come sempre approfitto del vostro tempo e vi scrocco consulenze a buon rendere
:) Sto meditando di rilasciare in opensource (GPL ?) un gestionalino molto
specializzato (top secret, per ora), ma prima di fare il “grande
passo” vorrei sentire i pareri del Gotha dell’informatica…

Ora come ora il programma è una web application “classica”:
- hibernate
- spring MVC
- JSP
- Database : Derby o MySql (Oracle e Firebird in lizza per la nomination)

Funziona tutto e sono molto soddisfatto (in particolare di Hibernate e Spring)
ma mi sono un po’ rotto le balle di questa impostazione, perché è sì molto
semplice da capire e da estendere, ma molto poco *agile*:
- sviluppo: tutti voi sapete benissimo che una web application page-centric
comporta tutta una serie di problemi; si va dalla gestione del workflow a
problemi di refresh, submit dei form quando clicchi sulla navigazione, eccetera;
- utente: il peggior difetto visibile all’utente è la lentezza dovuta al refresh
di pagina.

È ovvio dove voglio andare a parare: AJAX ;)

Ho fatto un’indagine molto ampia ma anche molto superficiale su diverse
tecnologie “AJAX”, e vorrei dei pareri aggiuntivi su quelle che ho
pre-selezionato, in ordine sparso:

- Direct Web Remoting (DWR)
- (DOJO oppure Yahoo! UI libraries) + serializzazione JSON lato server
- Google Web Toolkit (GWT)

E, già che ci siamo, una provocazione: che ne pensate invece di Java Web Start +
Spring HTTP remoting (o un altro meccanismo di remoting) ? In effetti Swing mi
piace moltissimo come tecnologia per realizzare gestionali…no…non ridete,
dico sul serio! Il problema è che non ho mai usato JWS e mi mette un po’ paura.

Aieoooòòò Grazie a tutti e…se qualcuno è interessato si faccia avanti ;)

Dimitri

(\_/) Questo è Bunny.
(°_°) Copia Bunny nella tua firma.
(_ _) Aiutalo a conquistare il mondo!


^ top

Risposta di Filippo

Aioo, ciao
Io punterei molto su gwt da quello che ho sperimentato è una vera
rivoluzione, considerando che l’unico punto debole era la licenza cosa
che è stata risolta ma ti consigluio di verificare.

ciao


^ top

Risposta di Massimiliano

ciao,sul mio attuale progetto stiamo usando parecchio AJAX, JSON, e tanto Javascript
(yahoo libs) … sicuramente gli utenti apprezzano tutti questi caricamenti
asincroni modernetti ma io comincio ad avere la nausea e rimpiangere i vecchi
tempi (JSP,PHP,fine). Ma forse sono rozzo e non ho il feticismo del css, o
stupidamente penso che una web application dovrebbe sembrare una web application
e non un programma client scritto in deplhi o VB. Tra l’altro a casa uso il C64
e basta.

Mamma che velenoso che sono :)

A parte gli scherzi, e’ una tecnologia approvata e collaudata … ti consiglio
solo di pensare quando metti in piedi il tutto che un giorno ti potrebbe
capitare di debuggarlo !

salumi


^ top

Risposta di Luca

Ciao bello,se vuoi stare sul web, prova a vedere un framework a componenti come
Tapestry 4.1.x o una cosa + facile da gestire (credo) come Wicket

(http://wicket.sourceforge.net/).

Tapestry 5 e’ in costruzione, e dovrebbe essere ‘na bomba (citazione:
“attento che non ti scoppi nel culo” !)

Tapestry 4.1.x integra le funzioni Ajax di Dojo e ha adattato il suo
ciclo di vita di pagina a questa feature; Wicket (progetto + giovane e
moderno) dovrebbe avere il supporto Ajax integrato nativamente.

Oppure potresti usare DWR e scrivere un pacco di codice js che copia i
dati ritornati dalla servlet nel DOM della pagina. Questa opzione puo’
andar bene per applicativi gia’ esistenti.

Per quanto riguarda dojo… i suoi widget visuali sono lenti (alcuni
sono over-ingegnerizzati).

Per i widget js della user interface prova avedere la libreria UI di
Yahoo o prototype + scriptaculous.

Attenzione che le librerie Ajax hanno un side effect: aumentano
considerevolmente il traffico di rete - chiamate asincrone a parte,
parlo della lista di include che hai su pagina html.
Ogni include genera una chiamata http get. Per ovviare a tale
problema, Dojo utilizza un sistema di build + compressione che
accomuna tutti i files usati in un unico file compresso.
In tal modo esegui un unico get. Attenzione inoltre al fatto che tutti
i tuoi files “statici” vengano correttamente cacheati dal browser.

Abilita inoltre la compressione http da parte del connector di tomcat
oppure usa (mi pare) il mod_gzip di apache se stai su intranet lente.

Per applicativi rich client, starei su Eclipse RCP / Netbeans RCP + un
middleware di comunicazione (spring remoting ?).
Attenzione che il problema dei rich client e’ la funzione di upgrade
del software. Molte aziende scelgono l’applicativo web per non avere
costi di manutenzione / installazione di software sui client. Le
piattaforme di cui sopra dovrebbero risolvere il problema tramite
l’update via rete.

A buon rendere,

Luca


^ top

Risposta di Pietro

Uhm, tutte le tecnologie citate sono per me o poco note, o totalmente
sconosciute. A eccezione di JSP, naturalmente. Le altre le definirei “alla
moda”, più che “classiche”… ma qui diventa questione di gusti.Non mi hanno mai convinto i fat client, non mi hanno mai convinto le applet, non
sono per niente convinto di AJAX.

Le pagine JSP hanno problemi di workflow, lo penso anche io. Ritieni che con
AJAX si risolvano? La lentezza del refresh, invece, non è mai stata un problema,
nei progetti a cui ho partecipato. Certo, se il tuo gestionale ha 200k utenti e
gira su un pc di seconda mano, le cose cambiano.

Java ha i package che partizionano lo spazio dei nomi, lo strong typing, la
verifica delle dipendenze al momento della compilazione/class loading.
Probabilmente i framework che menzioni cercano di mettere a disposizione qualche
cosa di simile.

Ah, dimenticavo: nemmeno i framework non mi hanno mai convinto molto.

Ora ti saluto, torno alle mie schede perforate.

Pietro


^ top

Risposta di Marco

Bravo, mi dai soddisfazioni… perchè non vieni a lavorare con me?
Ottima la scelta di Spring non altrettando per Hibernate io avrei usato iBatis
(ma se non hai voglia di scriverti l’SQL …).Ajax è un ottima soluzione anche se un po’ inflazionata. Ho usato tutte e tre le
tecnologie che hai citato, per dei prototipi che mi hanno permesso di trarre
alcune conclusioni del tutto personali.

Delle tre secondo me la migliore è DWR (sul mio blog c’è un esempio semplice
http://www.marcobazzoni.it/category/ajax/) perchè ti leva dalle palle javascript
se non per degli script custom, inoltre al libreria utils.js è decisamente
comoda e performante. Comunque è una tecnologia da usare con parsimonia però va
bene anche per il Web (io l’ho introdotta anche in http://www.tuttomoto.com,
finchè ero in Hachette).
GWT in teoria dovrebbe essere completa però non va molto bene secondo me perchè
è troppo “invadente” e non si integra facilemente con nessun MVC tanto meno con
spring. E tra l’altro secondo me ci sono anche dei bachetti mica male. DOJO non
mi piace e nemmeno le librerie di Yahoo! mi sembrano dei giocattolini per fare
le UI un po’ diverse.

Secondo me dovresti guardare di più ad altre tecnologie. Se vuoi rimanere su
AJAX ti consiglio ZUL (http://www.zkoss.org/) che ti consente davvero di pensare
la UI come un’insieme di Widget avanzate “Swing-like” tra l’altro gli script non
sono sola Javascript ma anche BSH.

Se invece vuoi delle cose più avanzate dovresti scegliere delle tecnologie che
ti permettono di creare delle vere e proprie RIA. Penso alle tenologie legate a
XUL: in particolare MXML di Adobe che ti consente di creare degli SWF in modo
programmatico (ho utilizzato MXML per un foto viewer sul sito di Tuttomoto
http://www.tuttomoto.com e ho fatto un gestionale assieme a mio fratello con
MXML + Spring + iBatis + JBoss + MySql) ha un suo framwork che può parlare
direttamente con degli oggetti Java, dei Bean di Spring, dei Web Service, o
direttamente con Hibernate anche via Spring; oppure potresti usare il motore XUL
di Mozilla (Gecko), disegnare le interfacce in XML, gestire l’interazione con il
server via SOAP tramite javascript e le librerie XPCONNECT tutto aggratis!!!!!!
(sempre sul mio blog trovi qualcosa http://www.marcobazzoni.it/2007/01/27/xul-vlc/)

Ci sono anche delle verticalizzazioni di XUL per disegnare via XML Swing oppure
SWT ma non mi convincono. Comunque qui http://xul.sourceforge.net/ trovi un
po’ di info.

Per quanto riguarda la licenza open source GPL secondo me va bene perchè è un
prodotto e non una libreria per cui e preferibile ASL.

Spero di essere stato utile.

Marco.


^ top

Conclusioni

Tutte le persone intervenute sono professionisti navigati e variano dallo sviluppatore sempre aggiornato alle ultime novità (Luca) al project manager che preferisce realizzare applicazioni solide e prevedibili (Pietro); in mezzo…tutte le sfumature possibili!

Penso che comincerò a sperimentare con Wicket e/o Tapestry, ma in futuro spero di avere la possibilità di provare Eclipse/Netbeans RCP, chissà…

  • dimitri's blog
  • Aggiungi un commento
  • 1574 letture
  • Share this

Potresti essere interessato anche a...

  • Schedulare i job con Quartz e Spring
  • Impariamo ad usare The Play Framework - I parte
  • Impariamo ad usare The Play Framework - III parte
  • Impariamo ad usare The Play Framework - IV parte
  • How to configure relative paths for Log4j using Spring

Navigazione

  • Contenuti recenti
  • Cerca
  • Tags
  • Articoli più letti

Seguimi

Follow @megadix

Dimitri De Franciscis - Consulente software freelance

Secondary links

  • Note legali
  • Pubblicità su www.megadix.it

Copyright De Franciscis Dimitri - p.iva 05327790969

RoopleTheme