Hvordan anbefales det å programmere skjema som går over flere sider?

[John-B]

Skal lage et bestillingsskjema som går over flere sider.

 

Noen som har erfaring med dette? Hvordan er det anbefalte håndteringen av variablene?

 

 

Jeg har brukt session før, men har hatt mye problemer med brukere som opplever at dataene ikke lagres eller plutselig forsvinner midt i prosessen. Mistenker muligens at det er webserveren som skaper problemene, men det er jo litt rart siden det tydeligvis kun er jeg som har problemer...

Kan jo hende det er jeg som bruke sessions feil også, selv om jeg ikke helt ser hvordan det kan skje. Er jo stort sett bare $_SESSION['var'] = "blabla" for å sette en session variabel, og deretter $variabel = $_SESSION['var'] for å hente den ut igjen?

 

Men er det bedre å lagre infoen i cookies (er ikke sensitive data)?

 

Noen som har eksempelkode/pseudokode på hvordan dere lager et enkelt script, som går over flere skjema-sider? Tenker da også litt på logikken i presentasjon av de forskjellige skjemaene, dvs hvordan scriptet vet hvilken side som skal vises etc.

Endret 8. desember 2009 av John-B

[gxi]

Du kan legge tidligere felt som hidden-input-felt i formen for hver side. Da bare genererer du en <input type="hidden" name="navn" value="verdi" /> for hvert enkelt felt som du putter inn i <form>-taggen. Fordelen er at du får alle felt med i POST-data på slutten og du slipper å lagre cookies hos klienten. Husk å escape value-verdien i feltet slik at det ikke blir problematisk å putte inn " i feltverdiene.

Endret 8. desember 2009 av gxi

[John-B]

Det er jo forsåvidt en mulighet, men har en følelse av at dette ikke er den mest optimale/anbefalte måten å løse dette på... Eller er det det?

 

Begynner å lure på om kanskje Ajax hadde vært lurt... At skjemaet kun er på én side, men nye felt legges til dynamisk etterhvert som brukeren fyller ut.

[Jonas]

Ved å ta i bruk Javascript til å gjennomføre sidebytter og beholde tidligere resultater i lokale variabler, så unngår du hele problemet med tilstander og det med å huske verdiene. Men det er ikke Ajax av den grunn. Slang sammen et raskt eksempel for å vise hva jeg mener.

 

Edit: Tips dersom du vil gjøre det på den måten: Lag først skjemaet i ren HTML og deretter modifiser det med javascript, slik at du beholder kompatibilitet med nettlesere uten javascript. Alistapart har en artikkel om akkurat dette.

Endret 9. desember 2009 av Jonas

[John-B]

Takk for svar.

 

Hensikten min med flere sider er at skjemaelementene som skal vises, blir valgt ut i fra hvilke valg bruker gjør. Å bruke denne javascript-metoden tror jeg blir tungvindt da, spesielt siden jeg ikke er særlig dreven i javascript. Med Ajax tenkte jeg at jeg i det minste kan gjøre sjekk av input direkte, server side med PHP (som jeg behersker mye bedre).

 

Men når dette er sagt - kan ikke huske å ha vært borti flerside-skjema som kun bruker javascript. Det burde vel indikere at dette ikke er den beste løsningen?

Endret 9. desember 2009 av John-B

[quantum]

Men når dette er sagt - kan ikke huske å ha vært borti flerside-skjema som kun bruker javascript. Det burde vel indikere at dette ikke er den beste løsningen?

Hvis du definerer «beste» som «det du har sett før» så har du selvsagt rett. Ulempen er at du avskriver alle innovasjoner som dårlige i samme slengen ... :-(

 

Det er mer og mer vanlig å kode gui i javascript på klientsiden, ref. GWT og lignende rammeverk.

[Wattengård]

Jeg ville bare lagret alt i databasen umiddelbart, men hatt en kolonne som heter "komplett" eller lignende. Denne er boolean og false/null som default. Når bruker har gått gjennom hele bestillingen med bekreftelse og alt så setter du den til true. Hvis kunden bryter så blir bare alt stående. Deretter kan du ha en prosess som går hver natt som sletter alle bestillinger som ikke har komplett=true.

 

Evt. kan man også ha en "lastentry" kolonne som settes til "now" hver gang man hopper fra side til side, så sjekker scriptet som sletter ukurrante bestillinger om "lastentry" er høyere enn f.eks. 15 minutter, slik at man ikke sletter bestillingen til en nattevandrer som er midt i bestillingsprosessen

 

-C-

[BlueEAGLE]

Det høres mer ut som en logisk brist i kodingen din.

 

Det er ikke nødvendig å "hente ut" variabler før bruk. Du kan bruke $_SESSION['var'] i skriptet ditt. Husk bare at når du vil interpolere variabelen i en streng så må du bruke krøllparanteser for eksempel slik: echo "Navn: {$_SESSION['navn']}";

 

Det jeg tipper skjer er at du har kode som skulle oppdatert sesjonen men som feiler og dermed "forsvinner" dataene. Det å jobbe direkte mot sesjonsvariabler forhindrer slikt.

[John-B]

Er jo klar over at det ikke er nødvendig å lagre $_SESSION['var'] til en egen variabel, men jeg gjør jo det for å forenkle koden (kortere navn, mer lesbart) og slippe nettopp {} for å interpolere.

 

Kan ikke se hvorfor dette skulle være et problem... Om det var steder i koden jeg hadde glemt noe ville jo det feilet hver gang, hos meg feiler det kanskje 1 av 100 ganger, og er ganske sikker på at det er webhosten som har trøbbel. Men hadde også en person på en gammel Win 2000 PC med IE6 hvor det var mye trøbbel. Cookies var påskrudd, men sessions virket tydeligvis ikke likevel.

Endret 12. desember 2009 av John-B

[BlueEAGLE]

..men jeg gjør jo det for å forenkle koden (kortere navn, mer lesbart) og slippe nettopp {} for å interpolere.

 

Dette er en "falsk" innsparing fordi det er dette som veldig ofte er årsaken til logiske feil.

 

Jeg har ofte sett igjennom kode og spurt meg "Hvor i pokker kommer denne variabelen fra?" så derfor vil jeg argumentere at det å flytte variabler fra en matrise og inn i det lokale omfanget gjør koden mindre lesbar.