Come in ASP.NET, gestisci sessioni e più schede?

Question

Ho scritto un'applicazione in ASP.net, progettata per consentire all'utente di aggiungere record a un database. La pagina viene impostata in modo che quando un utente aggiunge un record, il numero ID del record appena aggiunto viene impostato in sessione, la pagina Response.Reindirizza a un "Grazie per aver inviato". pagina, quindi reindirizza alla pagina originale per consentire ulteriori modifiche. Gli utenti possono anche utilizzare il pulsante Indietro in questa schermata per tornare alla pagina di aggiunta del record originale, che consente loro di apportare modifiche ai dati.

Tuttavia, ho scoperto che la memorizzazione dell'ID in sessione non è una soluzione terribilmente valida, in quanto un utente potrebbe provare a creare due documenti in schede o finestre diverse. Ho anche provato a impostare l'ID in un controllo letterale, ma questo causa il problema che quando l'utente utilizza il pulsante Indietro, il controllo letterale non è impostato sull'ID e vengono aggiunti nuovi record anziché uno che viene modificato.

C'è qualche tipo di soluzione per questo?

Answer 1

Domanda sciocca, perché l'utente può utilizzare il pulsante Indietro per modificare i dati appena accettati in un post?

Se la modifica dei dati pubblicati in precedenza è uno scenario comune, perché non reindirizzare a una pagina quando vengono accettati i dati che consentono loro di modificarli. Quindi, premendo il pulsante indietro, tornerebbero all'originale "pulito". inserire / aggiungere una nuova pagina di dati.

Questo darebbe i seguenti flussi Add-> [Post] - > > Modifica-; ..... Aggiungi- > [Posta] - > Modifica- > [Pulsante Indietro] - > Aggiungi- > [Posta] - > Modifica- > [Posta] - > Modifica ....

Answer 2

Consiglio di archiviare il tuo ID in QueryString. Dopo aver aggiunto il record, reindirizza al tuo "grazie". pagina, che quindi suppongo contenga un collegamento al modulo di modifica che genererai con l'ID nella stringa di query. Quando viene seguito quel collegamento, la pagina di modifica deve estrarre l'ID dalla stringa di query per caricare il record corretto da modificare.

Il modulo di aggiunta e modifica può anche essere la stessa pagina, quando viene fornito un ID nella stringa di query, il modulo sa di modificare quel record, altrimenti il ??modulo aggiunge un nuovo record.

Answer 3

Hai provato ad aggiungere l'ID nella stringa di query? Quindi puoi leggerlo e aggiungerlo alla sessione, se necessario (ad esempio, facendo clic sul pulsante Indietro su un utente).

Sembra che ci siano molti problemi che consentono la modifica di un oggetto in una pagina renderizzata quando si utilizza il pulsante Indietro. Sarebbe troppo dare loro invece un pulsante di modifica?

Answer 4

I controlli salvano il loro stato nel ViewState. Se scegli di utilizzare SessionState anziché ViewState per memorizzare le informazioni, i controlli salveranno il loro stato nello stato della sessione e non funzioneranno correttamente con più schede.

Non ho ancora trovato un modo per aggirare questo problema mentre utilizzo SessionState. La nostra soluzione era usare il normale ViewState.

Answer 5

Ho provato a memorizzare l'ID nella querystring (che va bene per la modifica), ma il problema è che le informazioni vengono archiviate nella sessione per quando usano il pulsante Indietro. Se l'utente fa quanto segue:

1. L'utente crea un record (1 ° record), l'ID viene passato nella stringa di query e temporaneamente memorizzato nella sessione.
2. L'utente crea un altro record (secondo record), l'ID viene passato nella stringa di query, temporaneamente memorizzato nella sessione.
3. L'utente utilizza il pulsante Indietro sul primo record per accedere alla pagina che non ha la stringa di query.

Probabilmente è uno scenario inverosimile, ma può succedere. L'unica soluzione che ho è quella di bloccare l'utilizzo del pulsante Indietro per tornare alla pagina di aggiunta, usando window.history.forward () in JavaScript. Ma questa come soluzione è terribile.

Answer 6

La mia domanda per te è: perché stai memorizzando qualcosa nella sessione per cominciare? Se riesci a evitare di archiviare qualcosa nella sessione, penso che starai meglio del tutto.

Answer 7

Dopo aver pensato a questo, la seguente sembra una soluzione decente al problema che ho descritto sopra?

• Quando si aggiunge per la prima volta un record, memorizzare un timestamp di quando è stato effettuato l'accesso alla pagina di aggiunta in un campo nascosto.
• Questo timestamp viene passato attraverso la sessione quando l'utente fa clic su Salva. Insieme all'ID.
• Se l'utente apre un'altra scheda contemporaneamente e salva, il timestamp della nuova pagina viene passato attraverso la sessione.
• Se l'utente tenta di accedere alla pagina di aggiunta del primo record (utilizzando il pulsante Indietro), il sistema cerca la sessione e vede se c'è un timestamp e se corrisponde a quello nel campo nascosto per quella pagina.
• Se non corrisponde, l'utente riceve un prompt e gli viene chiesto di modificare correttamente il record.

Sembra ragionevole o troppo complesso?