Newsgroup: it.comp.www.php
Titolo: Registrazione Account a più step

Salve.
Mi trovo ad affrontare una reistrazione utenti che deve procedere per
diverse pagine, ognuna delle quali registra diversi dati dell'account
in creazione.
La soluzione più logica sarebbe quella di portarsi dietro per tutte le
pagine i dati inseriti dall'utente, arrivando alla fine a generare la
insert, ma io ho scelto di mettere ogni step sul DB, identificando il
record in creazione con il session ID.
Qualcuno ha già affrontato problemi di questo tipo?
Sarebbe utile per me potermi confrontare con chi ha già tentato la mia
strada o ne ha trovate altre più semplici e sicure.

 strada o ne ha trovate altre più semplici e sicure.
La cosa più semplice è mettere tutto in sessione, alla fine della 
procedura salvi su DB.
Salvando i dati passo passo rischi di trovarti delle registrazioni 
parziali: a quel punto dovresti fare un controllo p.e. tramite cron che 
cancella le registrazioni parziali.
Un consiglio: fai una sola pagina (e non n pagine per i vari step) e 
metti in sessione lo step successivo da eseguire. Dopo aver elaborato la 
fase di post, fai un redirect alla stessa pagina. In questo modo eviti 
il problema del tasto back del browser.
Ovvero:
SESSION_STEP=1
step1: inserimento campi -> POST -> salvi i dati in sessione, 
SESSION_STEP=2 -> redirect della pagina su se stessa (a questo punto 
mostri i campi del II step)
	Francesco

 mostri i campi del II step)
Il tasto back serve.
Se un utente si accorge di aver sbagliato un dato nello step1 ed è
già allo step2, deve avere la possibilità di tornare indietro.

 scarti del db.
e se io mi loggassi mentre un altro utente non ha ancora completato la
registrazione, cancellerei i suoi dati parziali?
per usare cron comunque non e' necessario avere un server dedicato: puoi
impostare una crontab esclusivamente per il tuo utente
-- 
"We're just two lost souls swimming in a fish bowl -
year after year"

 
Capisco ma avere la schermata che ti dice "attenzione passaggio di dati 
(ovviamente l'ho scritta a caso)" non è molto piacevole. E' preferibile 
mettere nella pagina i tasti di previous-next
	Francesco

 
Non penso sia fattibile in hosting.
Un tempo c'erano dei server "cron" che ogni tot facevano una chiamata ad 
un certo url
	Francesco

 
Personalmente,
come evidenziato da altri, anche io sono solito salvare i dati parziali 
provenienti dai vari step in sessione.
Al termine della registrazione poi procedo con un insert Globale.
Unica differenzae che personalmente sto usando il metodo "Switch".
Mi trovo abbastanza bene e mi permette di schematizzare meglio i vari 
casi che possono generarsi durante le fasi diregistrazione (errori, 
Controlli non passati, etc.)
Saluti
T.

Naturalmente l'utente in creazione viene flaggato e se lascia la pagina
ha comunque associato un timestamp.
Si cancellerebbero gli utenti in creazione con un timestamp vecchio di
un'ora.
Salvare tutti i dati in sessione potrebbe essere una buona scelta (ci
posso salvare anche un array?), ma è più gestibile la cosa se si
usano più pagine.
La paginona unica che mostra i campi del form a seconda dello step
risulterebbe troppo pesante da caricare e comunque meno manutenibile.
p.s.
Non credo ci siano servizi di hosting che diano anche la possibilità
di sfruttare il cron, a meno di server dedicati.

 risulterebbe troppo pesante da caricare e comunque meno manutenibile.
Qui ti sbagli (secondo me). Pesante da caricare? No, poichè a seconda 
dello step fai quella o l'altra cosa. Come manutenzione se la strutturi 
bene non avrai problemi.
Non sottovalutare i problemi che può dare il tasto back del browser e, 
se lo fai a pagine separate, devi gestire anche l'accesso direttamente 
ad una pagina successiva alla prima (se l'utente ti mette la pagian 
step3.php, cosa accade?)
Del resto puoi anche gestire una sola pagina e includere a runtime la 
parte di codice necessaria a tale step (secondo me, il peggior modo per 
programmare!)
	Francesco

 Qualcuno ha già affrontato problemi di questo tipo?
<cut>
Io ho usato il pacchetto PEAR 
HTML_QuickForm_Controller(
http://pear.php.net/package/HTML_QuickForm_Controller
).
Ad ogni submit puoi associare un oggetto "action" che manipola i dati 
come vuoi te. Come per tutti i pacchetti PEAR ben fatti, c'è da 
"sciropparsi" un bel po' di documentazione.
Saluti

 Saluti
Ho dato una scorsa veloce al sito, ma per non sciropparmi tutta la
docuentazione, visto che l'hai usato, ti chiedo che concetto usava per
tenere traccia dei valori inseriti via via che si cambia pagina.
Sessione o database? (campi nascosti credo sia da pazzi...)

 
Sessioni. Però, se ti crei una funzione apposita che fa l'overload 
dell'action "process" (che processa il contenuto del form), puoi 
immagazzinare i dati *anche* nel database.
Saluti

 strada o ne ha trovate altre più semplici e sicure.
non sono certa che la soluzione che certe volte ho adottato sia la
migliore,
ma credo comunque che in alcuni casi possa essere una buona
alternativa.
Utilizzo una sorta di tabella di appoggio, in cui inserisco i dati "in
corso d'opera".
Alla fine, se tutto è andato a buon fine, cancello il record dalla
tabella di appoggio e la inserisco nella tabella definitiva.
In questo modo sono certa che nella tabella reale ci siano solo dati
completi e corretti.
E' poi possibile procedere ad una pulitura della tabella di appoggio,
per esempio cancellando tutti i record con timestamp < di n ore o di
cosa vuoi tu.
Cosa ne pensate? E' un metodo stupido o può avere un suo perchè? :-)
ciao!
mad

 cosa vuoi tu.
La questione è che la tabella, che sia di appoggio o definitiva con i
dati incompleti flaggati, la devi bonificare a mano o con un cron, che
non sempre viene fornito quando richiedi un hosting a pagamento.
Il problema che mi si presentava con la registrazione temporanea nel
db, era che lo username veniva bloccato finchè la tabella non veniva
bonificata.
Quindi un utente che voleva iscriversi con uno username utilizzato in
una registrazione incompleta, non poteva.

 una registrazione incompleta, non poteva.
utilizzando due tabelle, una di appoggio ed una definitiva, basterebbe
controllare che lo username non sia presente nella tabella definitiva.
Per maggiore sicurezza è possibile effettuare il controllo sulla tbl
definitiva subito prima dell'inserimento, magari gestendo i lock.
in questo modo le registrazioni incomplete non interferiscono con
quelle nuove.
Per la pulizia della tabella di appoggio, se non si ha a disposizione
un cron, si può lanciare una funzione che controlli timestamp e
pulisca in certi casi. Per esempio se il progetto ha un'area
amministrativa al login di questa.
In ogni caso il fatto di avere una tabella di appoggio sporca non
dovrebbe interferire con il buon funzionamento dell'applicazione.

 dovrebbe interferire con il buon funzionamento dell'applicazione.
Penso a delle select massicce.
Se ci sono il 10% dei record che sono spurie, la query è comunque
rallentata.
Il metodo di mettere, in uno script come il login, una query che
dovrebbe girare su un cron non mi piace, anche se sono stato costretto
a utilizzare questo metodo altre volte.

 a utilizzare questo metodo altre volte.
hai ragione, non piace neanche a me... però certe volte è l'unica
soluzione che ho trovato!