Newsgroup: it.comp.java
Titolo: Interfacce web

Buongiorno a tutti,
vorrei sottoporre al ng una questione. Sto seguendo un progetto che prevede
il porting di un piccolo gestionale su Web. Lato J2EE non ci sono grossi
problemi: lo sviluppo delle classi di business (EJB) e delle varie servlet
non ci da' alcun problema. Le magagne "vere" sono legate all'interfaccia web
del progetto: la gestione di popup di ricerca, il refresh delle pagine,
l'inserimento di dati "dinamico" con layer e "componenti" che compaiono e
scompaiono, la presenza di campi editabili in modo tale che, a fronte di un
inserimento su un singolo campo, si abbia immediatamente il post dei dati
sul server (con validazione, decodifica, controlli e tutto quanto) rallenta
incredibilmente lo sviluppo. Vorrei sapere, secondo voi, quale metodologia
convenga utilizzare. Ho pensato di ricorrere alle Applet, almeno per
implementare le interfacce più complesse, ma non sono sicuro che sia una
buona idea. Quali sono, secondo voi,  le "best-practices" in materia di
client web ?
Grazie in anticipo !
Scorpio.

 ha scritto nel messaggio 
news:32t11jF...@individual.net...

Beh certe applicazioni non possono essere portate pari pari su interfaccia 
web senza dover cambiare i componenti e a volte anche il codice sottostante.
Non ho capito bene le magagne di cui parli:
-popup di ricerca ok,
-refresh delle pagine che problemi da?
-l'inserimento di dati "dinamico" con layer e componenti che appaiono e 
scompaiono?
 -la presenza di campi editabili in modo tale che, a fronte di un 
inserimento su un singolo campo, si abbia immediatamente il post dei dati 
sul server?
Certamente un modello Client/Server come quello delle applicazioni web 
richiede principalmente che il client completi le sue operazioni e solo poi 
invii una richiesta al server. La cosa è spesso molto diversa in 
applicazioni non web. Tuttavia ci sono alcune variazioni a riguardo (ad 
esempio é possibile fare in modo che il server decida il refresh del client 
con alcune tecniche), ma non avendo capito i problemi che hai non posso dire 
nulla. 

 sul server?
Esempio: un form ha delle righe che vanno aggiunte o tolte dinamicamente.
Una riga è composta, per esempio, da tre o quattro input box (per dirla in
html); mettiamo ad esempio che sia una riga ordine, in cui il primo campo è
il codice dell'articolo, il secondo la quantità e la terza è il prezzo (che
è funzione della quantità). Scenario: l'utente aggiunge una riga: preme
un'immagine che corrisponde al comando "aggiungi" e SENZA REFRESH deve
vedere una riga aggiunta sulla sua pagina web. Scrive il codice articolo nel
primo campo e senza premere alcun pulsante viene valorizzata (con un submit
del frame nascosto) la quantità predefinita (funzione dell'articolo, e
memorizzata su un database) ed il prezzo (funzione dell'articolo e della
quantità), nonchè la decodifica. L'utente varia la quantità ? Perfetto: deve
essere variato anche il prezzo, leggendo da database sul server.
Inoltre, l'aggiunta di una riga comporta una insert / update della riga
ordine nel db; la cancellazione mi deve far scomparire la riga nel frame
corrente e deve, contestualmente, cancellare la riga anche dal database....
Ora, molti di questi eventi sono gestibili eseguendo un submit da un form
opportunamente progettato nel frame nascosto (questo è necessario perchè non
si deve vedere alcun refresh) , ad esempio scrivendo in javascript dei
gestori degli eventi onBlur o onChange. Però è chiaro che lo sviluppo di
pagine con requisiti simili richiede un lavoro non indifferente ma che,
soprattutto, ad ogni "nuova pagina" impone di cominciare praticamente
daccapo. Non so se esista una "programmazione a componenti" (non dico ad
oggetti) anche per HTML in modo tale che si possa riciclare con grande
flessibilità il lavoro già svolto.....
Premesso che le mie competenze "vere" sono in Java, e che di html e
javascript mastico quel tanto che basta per tirare a campare,sto valutando
la possibilità di utilizzare applet che renderebbero più gestibile (dal mio
punto di vista) l'interfaccia. Ma il ricorso alle applet è una buona idea ?
Sento parlare di JSF, ma non vorrei sprecare troppo tempo e buttarmi su
qualcosa di non soddisfacente....
Ti ringrazio ancora per la cortesia; spero di essere stato più chiaro
nell'esporre i miei dubbi....
Scorpio.

Sincemente ora che mi hai spiegato meglio, non ho mai affrontato tecniche di 
questo tipo, anche perché non vedo il motivo di nascondere quello che chiami 
refresh della pagina.
Se un utente sa di essere sotto interfaccia WEB é secondo me auspicabile che 
si veda ben distinto l'invio di informazioni dalla loro ricevuta, di modo 
che l'utente sa che tutto é andato a buon fine, secondo un modello che é 
abituato ad usare.
Così solo per curiosità, come mai si deve evitare il refresh a tutti i 
costi?

 costi?
Perchè se vi fosse il refresh gli utenti si lamenterebbero in quanto darebbe
loro fastidio vedere la pagina che si ricarica. Ti assicuro che non ti sto
prendendo in giro....
Ti ringrazio molto per la disponibilità.
Scorpio.

 prendendo in giro....
Invece di utilizzare un IFRAME nascosto puoi utilizzare l'oggetto 
XMLHttpRequest, che ti permette di eseguire delle richiesta HTTP verso
delle pagine in rete senza ricaricare la pagina corrente.
Qui alcuni riferimenti a risorse interessanti:
Dynamic HTML and XML: The XMLHttpRequest Object
http://developer.apple.com/internet/webcontent/xmlhttpreq.html
Using the XML HTTP Request object
http://jibbering.com/2002/4/httprequest.html
Qui inoltre c'è una libreria JavaScript cross-browser:
Cross-Browser XMLHttpRequest
http://www.scss.com.au/family/andrew/webdesign/xmlhttprequest/
Gaetano

>
Ciao Gaetano,
 grazie per la risposta. Proverò l'oggetto in questione:dalle pagine di 
documentazione che mi hai suggerito emergono caratteristiche interessanti, 
anche se l'interfaccia verso web dovrà massicciamente utilizzare XML.
Per intanto, grazie ed auguri !
Scorpio.
