Newsgroup: it.comp.java
Titolo: Uso di AJAX

Salve a tutti,
sto valutando la possibilità di ricorrere massicciamente ad AJAX per la 
realizzazione di applicativi web complessi... però, prima di buttarmici a 
capofitto - con  tutto il rischio di grandiose "zuccate" :- ) - mi 
piacerebbe sentire l'opinione di chi l'ha attivamente usato... è solo 
l'ennesima moda, o è davvero efficace ?
Grazie !
Scorpio. 


Il mio parere, se l'applicativo web è davvero complesso (e quindi si 
presume dovrà essere manutenuto e gestito a lungo), è di scegliersi la 
piattaforma che, sulla carta o meglio per esperienza, ti garantisca la 
massima affidabilità e longevità.
Se proprio decidi di usare AJAX evita quindi di scegliere qualcuno di 
quei prodotti che sembrano oggi avere molto appeal, promettendo la 
realizzazione di interfacce in modo semplice, visuale, guidato etc. ma 
che magari ti nascondono troppo quello che c'è dietro (sì mi duole 
ammetterlo ma sto pensando anche a JSF). Il rischio è che tra due anni 
il cliente ti chiede una modifica un po' "strana" e tu ti trovi a dover 
fare i salti mortali tra documentazione introvabile, bug del tool e 
quant'altro.
pole
PS: son sempre più convinto che il web sia fatto per le *pagine*; per le 
applicazioni davvero serie continuano ad essere decisamente meglio i 
*veri* client, quelli con tanto di link sul desktop e che magari si 
autoaggiornano con webstart ;) Poi le magie sul web preferirei lasciarle 
fare a google che ha gente da farci lavorare sopra..
-- 
ammentos - a lightweight persistence framework for JDK5
http://ammentos.biobytes.it
Flash tutorial: 
http://ammentos.biobytes.it/quickstart/quickstart.html

 realizzazione di applicativi web complessi...
La mia esperienza mi dice che la complessita' dell'applicazione cresce
esponenzialmente con AJAX!
Non ho mai usato frameworks preconfezionati tipo GWT perche' temo che
siano limitanti essendo quello di AJAX un mondo relativamente nuovo,
ma ho usato solamente librerie javascript (jquery) per semplificare la
scrittura del codice lato client.
Con AJAX perdi il presupposto: 1 pagina web = 1 funzionalita'  e
questo ti obbliga a struttare diversamente il tuo progetto.
La cosa piu' fastidiosa che ho riscontrato e' stata la gestione degli
errori, che ho trovato davvero frustrante. Gli errori lato server devi
per forza di cose gestirli lato client (da javascript) e non e' facile
trovare un modello di programmazione davvero efficace per
centralizzarne la gestione; si tratta in ogni caso di un layer in piu'
da aggiungere ad un'applicazione tradizionale.
--
SoulSpirit

 Scorpio.
 
Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/



Valuta attentamente. Perchè se hai un applicativo web complesso AJAX
aggiunge complessità, non la riduce.

 fare a google che ha gente da farci lavorare sopra..
Personalmente mi trovo assolutamente d'accordo con te, e, anche se penso che 
non te ne ricorderai, tempo fa avevo risposto ad un tuo post su questo n.g 
in cui ipotizzavi la necessità di avere codice distributo sia sul server che 
sui client - o qualcosa di simile. Già allora ero convinto che il vero 
problema del web è l'interfaccia, che non può (ancora) essere potente come 
quella di un client "vero".
Ma se si parla, soprattutto in certi ambienti, di un ritorno al client 
server si rischia di venire lapidati (in senso figurato, ovviamente).....
Saluti,
    Scorpio.

da aggiungere ad un'applicazione tradizionale.
Beh,per certi versi poter eseguire delle chiamate remote via AJAX ad uno 
stessa servlet può tornar comodo; se, per esempio, volessi eseguire una 
decodifica di un campo "articolo" in più pagine, a fronte, per esempio, di 
un evento onBlur o onChange, potrei *sempre* richiamare lo stesso codice 
verso una certa servlet... in questo modo, poi, le servlet altro non 
sarebbero che dei provider di servizi... e non dei controller / model di una 
certa applicazione web.
Posso chiederti come poi sono andate a finire le tue esperienze in merito ?
Scorpio.
--
SoulSpirit

 server si rischia di venire lapidati (in senso figurato, ovviamente).....
Ripeto, mi chiedo il perché: mancanza di skill lato desktop? Ostinazione 
dei clienti a voler usare per forza il browser?
La mia opinione è molto semplicemente che le potenti "lobby" di Java 
girino per forza di cose intorno al mondo JavaEE e degli appserver, 
perché è un settore in cui è più facile giustificare le "cifre".
pole
PS: spero di non creare flames, mi considero anche io uno sviluppatore 
web malgrado tutto.


> ovviamente).....
p> Ripeto, mi chiedo il perché: mancanza di skill lato desktop?
No.
p> Ostinazione dei clienti a voler usare per forza il browser?
Si.
Sopratutto da parte di quei clienti che utilizzano il web solo per
la presentazione e delegano ad altri sistemi l'elaborazione.
p> La mia opinione è molto semplicemente che le potenti "lobby" di
p> Java girino per forza di cose intorno al mondo JavaEE e degli
p> appserver, perché è un settore in cui è più facile giustificare le
Anche perché lì Java è una potenza. Sul desktop, quando fu il tempo di
scegliere,  Java fallì.  Tra l'altro  dovrebbero risistemare  Java Web
Start in modo che funzioni meglio con tutte le distribuzioni Linux.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 Start in modo che funzioni meglio con tutte le distribuzioni Linux.
Sviluppo e lavoro prevalentemente su Linux (anche con JNI) e 
distribuisco ormai prevalentemente con webstart. Che problemi riscontri 
in particolare?
pole


> Linux.
p> Sviluppo e lavoro prevalentemente su Linux (anche con JNI)
Abbiamo scaricato  tempo fa un  prodotto libero, slide se  non ricordo
male, e non riuscivo ad avviare la procedura di WebStart.
Ho la 1.4.2 ripacchettizzata Debian con il metapacchetto.
Altra  cosa che  ho  sperimentato  (oltre alla  lentezza  a creare  le
finestre)  è che avendo  abilitato i  thread nativi,  applicazioni che
fanno un  certo uso  del multithreading si  impallano grazie  al Motif
nascosto sotto il cofano.
Su questo punto confido molto nella liberazione del codice :)


 Posso chiederti come poi sono andate a finire le tue esperienze in merito ?
Ne ho circoscritto l'utilizzo alle parti di programma "a basso
impatto" come ad esempio il caricamento dinamico di tendine o i
suggest di google suggest, evitando assolutamente di utilizzarlo in
transazioni di una certa delicatezza.
Ora che ho una certa esperienza in merito, mi sento di consigliarlo ai
miei clienti solo in particolari ambiti, a meno che questi non abbiano
voglia di pagare il non indifferente sforzo aggiuntivo che ajax
richiede.
--
SoulSpirit

 è un settore in cui è più facile giustificare le "cifre".
Sottoscrivo TUTTO quello che hai postato sull'argomento, ma su queste ultime 
due righe vorrei
aggiungere qualche pensiero. Non so a quali lobby tu ti riferisca, se ai 
vendor di appserver o
grandi società di consulenza, ma in entrambi i casi puoi avere ragione: 
chiunque, anche mio nonno
potrebbe scaricarsi NetBeans che è potente e *semplice* e cominciare a 
scrivere software che
per quanto semplice, sia efficace.
Far funzionare un appserver invece richiede uno studio preliminare (che per 
il consulente
significa fatturato) e, oltretutto, a meno che non si usi JBoss, acquistare 
un appserver commerciale
(che significa fatturato per il vendor).
Va da sè che appserver non significa webserver: chiunque conosca J2EE 
inorridisce di fronte a questa
semplificazione. Come dovrebbe inorridire qualunque sviluppatore Java quando 
sente, ancora, ripetere
che "Java se non sul Web non serve a nulla".
Mi viene però, senza voler anch'io innestare polemiche inutili e squallide, 
chiedere se davvero Java sul desktop possa fare concorrenza a .NET che, al 
di là della partigianeria con paraocchi, per scrivere applicazioni client su 
windows è straordinario. Ho visto in azione l'ultima versione di  Visual 
Studio .NET e onestamente nessuno fra gli IDE per Java che ho utilizzato ha 
la stessa velocità e flessibilità. E soprattuto: integrazione con prodotti 
Microsoft (che sono quelli che poi alla fine gli utenti usano per il loro 
lavoro) da fuochi d'artificio, tipo "pilotare" fogli di lavoro Excel da 
un'applicazione .NET.... Cose che in Java o non si possono fare o richiedono 
il ricorso a librerie native.
Noi ad esempio scriviamo anche applicazioni per PDA: usando applet Java (sì, 
applet perchè altrimenti non potremmo creare interfacce sufficientemente 
potenti con HTML; e l'uso di JME ci è stato "proibito")  otteniamo programmi 
efficaci, ma poco efficienti, in tempi molto lunghi. Se avessimo scelto .NET 
almeno su quella piattaforma (eseguendo chiamate ad un appserver remoto, 
ovviamente: sono contrario a distribuire la logica di business sui client, 
se si può) avremmo una produttività più elevata, perchè mentre .NET su 
Windows Mobile è integrato, Java NO e serve raccattare qualche plugin per 
lavorarci.
Scorpio. 

> "cifre".
S> Sottoscrivo TUTTO quello che hai postato sull'argomento, ma su
S> queste ultime due righe vorrei aggiungere qualche pensiero. Non so
S> a quali lobby tu ti riferisca, se ai vendor di appserver o grandi
S> società di consulenza, ma in entrambi i casi puoi avere ragione:
S> chiunque, anche mio nonno potrebbe scaricarsi NetBeans che è
S> potente e *semplice* e cominciare a scrivere software che per
S> quanto semplice, sia efficace.
S> Far funzionare un appserver invece richiede uno studio preliminare
S> (che per il consulente significa fatturato) e, oltretutto, a meno
S> che non si usi JBoss, acquistare un appserver commerciale (che
S> significa fatturato per il vendor).
Il software  per quanto  semplice ed efficace,  regge al  carico degli
utenti?
Scala ?
Permette transazioni, magari distribuite ?
Ajax  permette di migliorare  l'interfaccia utente  delle applicazioni
web (sempre  che sia utilizzabile,  che una applicazione che  usa Ajax
per forza  di cose  funziona solo ed  esclusivamente con  JavaScript -
l'unica soluzione e` scrivere DUE applicazioni). 
Ajax non fa nulla a oltre l'interfaccia. Dopo c'è altro.
E nessuno strumento, per quanto potente fa un buon programmatore.


 E nessuno strumento, per quanto potente fa un buon programmatore.
A parte quello che lo strumento lo ha scritto :) Sante parole.
pole
