Home Page
Articoli
Tips & Tricks
News
Forum
Archivio Forum
Blogs
Sondaggi
Rss
Video
Utenti
Chi Siamo
Contattaci
Username:
Password:
Login
Registrati ora!
Recupera Password
Home Page
Stanze Forum
ASP.NET 2.0 / 3.5 / 4.0
PostBack e reload della pagina
lunedì 18 ottobre 2010 - 18.48
Elenco Threads
Stanze Forum
Aggiungi ai Preferiti
Cerca nel forum
Elenco Tags
VB.NET
|
.NET 4.0
|
MySQL 5.1
|
Internet explorer 8.0
ravalon
Profilo
| Expert
689
messaggi | Data Invio:
lun 18 ott 2010 - 18:48
Salve ragazzi,...mi succede una cosa che non riesco a capire..
In una pagina di un carrello che usa AJAX, uso un bottone che fa il postback sulla pagina finale di acquisto....fin qui tutto bene...
Ho voluto provare a vedere cosa succede se ricarico la pagina finale di acquisto....risultato....mi richiama anche la pagina precedente, quella che ha scatenato il postbackurl...
Questo non mi va bene poichè inserisco l'ordine alla pressione del bottone che fa il postback, per cui se l'utente dovesse ricaricare anche per sbaglio mi fa l'inserimento due volte...
però non capisco perchè mi ripassa sul codice della pagina precedeteeeee....
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
lun 25 ott 2010 - 11:27
>Salve ragazzi,...mi succede una cosa che non riesco a capire..
Ciao
>Ho voluto provare a vedere cosa succede se ricarico la pagina
>finale di acquisto....risultato....mi richiama anche la pagina
>precedente, quella che ha scatenato il postbackurl...
>Questo non mi va bene poichè inserisco l'ordine alla pressione
>del bottone che fa il postback, per cui se l'utente dovesse ricaricare
>anche per sbaglio mi fa l'inserimento due volte...
puoi postare un po' di codice? Così possiamo aiutarti meglio..
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT
http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
ravalon
Profilo
| Expert
689
messaggi | Data Invio:
lun 25 ott 2010 - 15:54
Ciao, siccome nel frattempo non ottenevo risposte, ho rovistato un po per la rete...
Ho trovato un articolo di ASPALLIANCE.COM in cui uno sviluppatore affrontava proprio il problema del refresh su pagine che effettuato una insert su db...
Dopo varie prove con l'uso di Session, cookies, controlli sul browser, leggo che la soluzione migliore, l'unica priva di effetti collaterali e indipendente da sessions e browser è effettuare un controllo sull'esistenza dei dati inseriti nel db, nel qual caso dobbiamo saltare la routine di inserimento....
Ora sto studiando un metodo valido...
Avevo pensato ad una cosa del genere...
All'inserimento dei prodotti sul carrello creo un INT random e lo associo ai prodotti dell'utente sul db....quindi ogni prodotto sul carrello avrà un campo con questo intero...ovviamente ogni intero dovrà esistere una sola volta sul db e prima di generarlo farò opportuni controlli sul db...
Mi porto dietro questo numero (che quindi è univoco per l'utente e per un tot di prodotti) e lo scrivo su una tabella del db al momento della conferma finale (tipo tabOrdini) con un boolean IsPayed=false, ossia è inserito sul db quindi l'utente ha confermato ma non ha ancora pagato....ad ogni modo ha già premuto il bottone di conferma finale...
Nel caso in cui c'è un refresh della pagina, avrò sempre il numero Intero generato per i prodotti del carrello e controllerò se questo intero è gia' presente per quell'utente nella tabella degli ordini generati.....se lo è salto la procedura di inserimento che altrimenti sarebbe duplicata, altrimenti la eseguo....
Eviterei quindi il problema totalmente via SQL con delle semplici interrogazioni...
Potrebbe funzionare come idea ?
alx_81
Profilo
| Guru
8.814
messaggi | Data Invio:
mar 26 ott 2010 - 09:51
>Potrebbe funzionare come idea ?
da come la illustri sì, ma senza aver visto codice o senza avere la conoscenza del vero problema non posso darti certezze
. Comunque facci sapere
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT
http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
ravalon
Profilo
| Expert
689
messaggi | Data Invio:
mar 26 ott 2010 - 17:29
Hai ragione, tengo più a precisare la tecnica che ho usato in quanto forse qualcun altro potrebbe trovarsi nella mia identica situazione...
Ho apportato alcune modifiche all'idea iniziale che vi illustro...comunque funziona !!!
PREMESSE:
1) Il carrello di ogni utente esiste finchè non si conferma un'ordine, per cui se ci trovo qualcosa dentro vuol dire che ancora non ho confermato l'ordine...se lo avessi confermato i prodotti nel carrello sarebbero trasferiti verso una nuova tabellla...
2) Il carrello è persistente sul db, se anche l'utente esce, quando rientra ritrova tutti i suoi prodotti sul carrello in quanto sono legati all'ID dell'utente che ha fatto il login.
NECESSARIO:
1)Tabelle necessarie per questa tecnica che bypassa il problema del refresh della pagina per quanto concerne insert multipli sul db.
a)tabCarrello
b)tabOrdini
c)tabCodOrdine
d)tabOrdiniDettagli
2) Routine di creazione Intero Random che andrà a comporre quello che il CODORDINE
PERCORSO LOGICO:
1)Al momento dell'inserimento del primo prodotto sul carrello (cioè quando è vuoto), l'engine controlla sulla tabCodOrdine se esiste un CodOrdine (Intero random) per l'ID dell'utente loggato (mantenuto in una session)...
l'intero CodOrdine dovrà essere univoco, cioè esistere una sola volta sia sulla tabOrdini che sulla tabCodOrdine, per cui la routine di generazione dovrà anche controllare se il numero generato randomicamente è già esistente in una di queste due tabelle .
a)Se non esiste, ne viene creato uno nuovo che viene scritto nella tabCodOrdine
b)Se ne esiste già uno, viene riutilizzato
I prodotti vengono cosi aggiunti al carrello mentre nel frattempo sulla tabCodOrdine è stato generato questo intero CodOrdine
Il CodOrdine deve essere mostrato come riferimento in una label (o altrove) all'iterno del carrello, in modo che sia sempre visibile e soprattutto riutilizzabile alla fine del processo (vero motivo per cui esiste)
2)Al momento della conferma del VAI ALLA CASSA, cioè quando si sceglie di accettare l'ordine, si mostra un riepilogo all'utente trascinandoci dietro il valore del CodOrdine in una label (ad esempio)....si mostra poi un bottone di VAI AL PAGAMENTO che conferma in maniera assoluta l'ordine al 100% permettendo cosi all'utente di vedere un'ultima volta quanto spende (cosa lo ha visto prima) e i dati per il ricevimento, spedizione e pagamento....
cliccando sul VAI AL PAGAMENTO, si scrive ogni dato sul db....qui viene il bello...
Si verifica che esista un CodOrdine collegato all'ID dell'utente loggato sulla tabCodOrdine, facciamo che :
a)lo si prende e lo si confronta con quello che ci siamo portati dietro (CodOrdine come valore all'iterno di una label ad esempio)
b)se corrispondono vuol dire che esistendo ancora nella tabCodOrdine non esiste ancora sulla tabOrdini.... lo si scrive sulla tabOrdini assieme ai vari dati generici dell'ordine, lo si cancella dalla tabCodOrdine....di fatto la tabCodOrdine fa da contenitore temporaneo....
c)Si scrive sulla tabOrdiniDettagli tutti i dati dei prodotti inseriti nel carrello collegandoli con l'id dell'ORDINE appena inserito, legando di fatto la tabOrdiniDettagli con la tabOrdini (ogni prodotto relativo alla tabOrdiniDettagli avrà un ID riferito alla tabOrdini creando cosi una join)
Queste 3 procedure vanno svolte tramite una TRANSACTION per garantire le proprietà ACID del db.
A questo punto abbiamo
1)un nuovo record sulla tabOrdini
2)Nessun record sulla tabCodOrdine per quell'utente
3)il Carrello dell'utente è vuoto perchè l'ordine è già stato inserito
IL REFRESH:
Se l'utente refresha la pagina manualmente, senza una procedura di controllo nella routine di scrittura su db, essendo un postback viene rieseguito tutto il codice, compreso l'inserimento...ed essendo un postback il valore del CodOrdine (l'intero generato randomicamente) viene mantenuto....
Per questo poco prima della parte DISPOSITIVA, cioè di scrittura, è necessario fare i seguenti controlli (e qui si spiega la parte finale del significato del valore CodOrdine)
Ecco i due casi che vanno controllati.
a)Se per l'ID dell'utente loggato non esiste il valore CodOrdine (mantenuto in una label) sulla tabCodOrdine ma esiste sulla tabOrdini, vuol dire che l'ordine è già stato inserito....infatti la tabCodOrdine esiste fino a che l'ordine non è completo, funzionando cosi da contenitore temporaneo per verifica...
In questo caso SALTO LA PROCEDURA DI INSERIMENTO e RIMANDO L'UTENTE ad una pagina di riepilogo ordini (cosi se ritorna sul carrello lo trova vuoto mentre potrà vedere che c'è un nuovo ordine)....si perderà anche traccia cosi del valore CodOrdine che era mantenuto in una label (o altro controllo server-side)
b) Se per l'ID dell'utente loggato esiste il valore CodOrdine (mantenuto in una label) nela tabCodOrdine ma non esiste sulla tabOrdini, allora l'ordine non è stato completato, cioè il bottone VAI AL PAGAMENTO CHE FA SCRIVERE I DATI SUL DB NON E' ANCORA STATO PREMUTO....
In questo caso FACCIO ESEGUIRE LA PROCEDURA DI INSERIMENTO ORDINE...
LE pagine ed il percorso per questa tecnica, che comunque descrive un carrello della spesa per commercio elettronico sono questi
Carrello.aspx --> verifica dati --> Vai alla cassa --> Acquisto.aspx ---> riepilogo dati ---> pressione bottone VAI AL PAGAMENTO --> scrittura su DB previo controllo come descritto
Spero che nonostante l'essere stato prolisso abbia spiegato bene la procedura, se mai qualcuno ne vorrà prendere spunto, se mai potrà essere utile a qualcuno....
Penso che una community sia bella perchè tutti condividono quello che sanno, non solo per chiedere, ed ho voluto dare il mio contributo...
Magari questa struttura non piace perà funziona....
Torna su
Stanze Forum
Elenco Threads
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?
Dopo esserti registrato potrai chiedere
aiuto sul nostro
Forum
oppure aiutare gli altri
Consulta le
Stanze
disponibili.
Registrati ora !