Newsgroup: it.comp.java
Titolo: tasto back e webapps

salve...
come da oggetto, come gestite il tasto back del browser nelle applicazioni
Web??
No, non sto parlando dei soliti trucchetti per disabilitare il tasto destro
ecc... ma di come comportarsi lato server...
Esempio 1). Un utente ha appena salvato una form di modifica, invece di
riattivare la funzione "Modifica" è molto più comodo fare back, cambiare la
form e ripremere Salva.
Qui il tasto back è benvenuto.
Esempio 2). Un utente ha appena confermato una form per un ordine, fa back
per corregerlo e ripreme ordina. Nella sua mente pensa solo di aver corretto
un ordine esistente, in realtà ne ha introdotti 2
Qui il tasto back del browser è nocivo...
IMPORTANTE:  non vi focalizzate sul fatto che è ho parlato di ordini.
I  2 esempi vogliono solo sottolineare la differenza tra form "submittabili"
(perdonate il termine) più volte
senza problemi (e che hanno anche il pregio di essere comode per l'utente) e
form "più delicate" che
se riinviate al server generano "duplicati".
Che tecnica usate nelle vostre webapps??
a) ve ne fregate allegramente lasciando che si genrino doppioni, poi tanto
saranno problemi poi?
b) attivate sistemi anti invii-duplicati (tipo parametro hidden nella form
da confrontare con attributo in session che una volta utilizzato viene
eliminato (una specie di one time password))? NB: in questo modo però
l'utente si accorge che non poteva ripetere l'operazione mediante back, solo
dopo aver speso del (eventualmente molto) tempo a risistemare una form che
non potrà essere accettata
c) usate solo sistemi lato cliente per "limitare" (o tentare di impedire) il
back? (cosa che ho notato fa molto incazzare l'utente)
d) altro?? ovvero ditemi la vostra tecnica!!!
Grazie a tutti

 non potrà essere accettata
Siccome stai permettendo (per tua iniziale ammissione) il back, quindi senza 
cercare soluzioni lato client (che tanto non sono sicure in nessun caso), 
non hai nessuna possibilita' di evitare cio'. Al massimo puoi fare una 
chiamata asincrona e visualizzare un messaggio all'utente. 

 chiamata asincrona e visualizzare un messaggio all'utente.
umh... ok...
scusami se mi permetto: ma tu come gestisci la cosa?

 back? (cosa che ho notato fa molto incazzare l'utente)
E che non funzionano con tutti i browser.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Grazie a tutti
Il problema è in parte logico/semantico: quando un utente ti invia un 
nuovo POST, come fai a stabilire cos'ha nella testa?
Vuole fare un nuovo ordine o si è sbagliato?
Probabilmente dipende dall'applicazione: se serve per il data entry, è 
più facile che siano record diversi (eventualmente potrebbe essere utile 
un controllo che almeno un campo abbia dati differenti da quelli già 
registrati, ma anche in questo caso si può solo mandare un allarme e 
chiedere conferma, non supporre un errore), mentre il carrello degli 
acquisti di un sito per utenti "consumer" dovrà ragionavolmente supporre 
che il nuovo invio sia una rettifica del precedente.
In entrambe i casi, non mi sembra privo di senso l'uso di un campo 
hidden, anche se mi parrebbe più ragionevole farlo funzionare al 
contrario (metto la variabile hidden in sessione quando ho ricevuto 
l'ordine, controllando che non sia già presente: se una apre due browser 
e invia gli stessi dati, probabilmente sa cosa sta facendo...)
Ma, a questo punto, tanto vale usare i dati stessi, magari in forma di 
un digest, per evitarne la duplicazione.
Ciao.