Newsgroup: it.comp.java
Titolo: Tornare indietro con il browser in un'applicazione web

quando un utente cerca di accedere alla pagina precedente cliccando il 
pulsantino del browser, in un'applicazione web, si possono sollevare grossi 
problemi, giusto?
Il "back" recupera la pagina dalla cache violando il flusso di controllo 
deciso dal programmatore.
E' un problema risolvibile, o non c'è nulla da fare se non dire all'utente 
di non usare quel pulsante in un sito dinamico? 

Ciao,
potresti provare a mettere la seg. istruzione javascript al load della
pagina:
history.back(-1);
Stefano

 di non usare quel pulsante in un sito dinamico? 
Il programma deve fare il suo, cioč definire la sequenza di (chiamiamole 
cosě) action per completare una determinata operazione. Se l'utente 
torna indietro, ci sono due ordini di problemi che perň NON devono 
disorientare il programma:
- I dati della pagina abbandonata non vengono inviati al server, cavoli 
dell'utente (99% dei casi č quello che voleva)
- Se il browser ricarica dalla cache, la nuova pagina non viene 
rinfrescata dal server (c'č una direttiva da mettere sulla pagina per 
indicare che la stessa non deve essere cachata)
Tranne casi particolari (es un form che assolutamente non puň essere 
inviato al server piů di una volta), un programma web dovrebbe essere 
robusto rispetto a queste situazioni. Se va in crisi, vuol dire che ha 
un vizio progettuale.

 Il "back" recupera la pagina dalla cache violando il flusso di controllo
Il Problema del back e' un problema che coinvolge anche i bookmark, ossia il
digitare l'url di una pagina qualsiasi della tua applicaione che non sia la
home
Per quanto riguarda la domanda specifica che io sappia non si puo' togliere
il pulsante,
provero' anche io la proposta di stefanonm
Per quanto riguarda invece che succede ci sono i seguenti casi
1. La pagina non usa nulla della Session, in questocaso dovrebbe funzionare
il back e i bookmark.
2. La pagina usa la session ma non c'e' un flusso specifico. Per esmpio i
dati di login. In questo caso va il back ma non il bookmark
3. La pagina usa la session e c'e' un flusso obbligato. per esempio in un
contratto a 8 steps probabilmente nn ppuoi passare dallo step 6 al 3, il che
non ha senso ma con 3 colpi di back ci vai.
A questo punto e' tutto fuori controllo e + che avvisare l'utente all'inizio
di non tornarenon puoi fare altro
In questo caso chiaramente anche il bookmark non ha senso che ti faccia
entrare dritto allo step 3 se nonhai quelli prima
4. Altri casi come ha giustamente detto vincent sono patologici. cioe' se
non sei nel caso (3) e usi dati in session vitali hai sbagliato a
progettare. Se usi la session come cache di prestazioni devi sempre
controllare che se non esiste l'ogggetto lo ricrei , cosi' puoi anche fare
balancing
ciao Nicola
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

uno dei trucchetti più usati è quello di far scadere la pagina appena
emessa. Nel senso che la pagina che mandi al client è già scaduta, quindi se
ricaricata da un tipico errore di "pagina scaduta".
Ad ogni modo si consiglia di rivedere l'applicazione. Con Struts (e non
solo) puoi mettere in piedi il discorso dei TOKEN.

 di non tornarenon puoi fare altro
Si, però se vuoi non perdi il controllo. L'utente torna indietro da 6 a 
3, ma se poi vuole arrivare in fondo deve riprendere gli step. 
Eventualmente le pagine 3,4 e 5 vengono inviate più volte, si tratta di 
decidere cos'è più idoneo fare in questi casi. Potrebbe andar bene che i 
dati re-inviati vanno a semplicemente sostituire quelli precedenti, e 
quando reinvia una pagina già visitata la ripresenta popolata dei dati 
immessi in precedenza. Insomma, questo non è un problema.
Il problema semmai in questi casi può essere un'altro: cioè, se l'utente 
"a mano" salta uno o più step. Quì ti viene in aiuto struts.


E' chiaro che se tutto si puo' fare col SW, basta che vedi il cane AIMO ( mi
pare si chiami cosi') della Sony
:-)
Hai una scelta
 Dici all'inizio che il back e' vietato
Se invece devi controllare sono d'accordo che tu puoi gestire le anomalie.
Nel caso del contratto potresti verificare ogni volta se vi sono alcuni dati
e se uno va in back li modifica anziche inserirli o cose cosi'.
Pero' potrei entrare col bookmark allo step 6 e potresti redirigerlo al 2 in
automatico se aveva fatto l'1 eccetera.
Ci sono casi in cui la gesitone dell' "Utente matto" e' molto + complessa di
un contratto a 6 step e diventa a una macchia a stati complessa.
Insomma diventa + una questiondi tempi di sviluppo e costi alla fine.
Aimo del resto ci hanno impiegato anni a farlo.


 ha scritto nel messaggio 
news:d5o5tj$p1q$1...@carabinieri.cs.interbusiness.it...

Uso Struts, e se ho capito bene devo fare:
- saveToken in un Action per mettere le azioni associate alla form in 
"transazione".
- usare html:form nella jsp (che genera un campo hidden con il token).
- se  isValidToken nella action é uguale a true allora esegui l'azione, 
resettare il token, salvare il token resettato (chiude la transazione).
Basta così?

 ha scritto nel messaggio 
news:427f44d5$0$2180$5fc...@news.tiscali.it...

Grazie a tutti comunque.