Archief - Aanpak 'probleem', hulp welkom

Hi webdevelopers

Voor het bedrijfje van mijn ouders ben ik een reservatietool aan het maken dat zal draaien op een website in PHP. Het is dus de bedoeling dat mijn ouders via een website reservaties kunnen toevoegen en beheren. Nu, omdat een reservatie nogal veeeel informatie vraagt, zou ik dat willen opsplitsen in stapjes.

Tijdens het aanmaken van een reservatie doorloop je dus een soort van wizard. Nu vraag ik me af hoe ik het best omga met de tussentijdse informatie van die wizard. Alles zal waarschijnlijk in forms gepost worden dus ik moet die informatie ergens kwijt. Dan zijn er twee mogelijkheden dacht ik:

* Informatie per stap wegschrijven naar DB
* Informatie lokaal bewaren (session bvb) en op het einde alles wegschrijven.

De eerste methode lijkt me het veiligst, als er bij de laatste stap iets gebeurt, bvb browsercrash, dan ben je al die voorgaande info niet kwijt. Maar dan zit ik met het probleem: hoe ga ik dat record stap na stap blijven bewerken? Het moet echt waterdicht zijn dus liefst vanal zou ik via een uniek id werken in de DB, maar tot op heden heb ik nog geen manier gevonden om tijdens het aanmaken van een record meteen ook zijn id te laten terugkrijgen ipv een 1 om aan te tonen dat er één record gemaakt werd. Zonder dat ID kan ik dus weinig doen. Ja, ik kan wel heel veel WHERE IS-controles gebruiken, ook bvb een huidigeDatum instoppen en dan het id van het nieuwste record opvragen, maar ik heb daar zo mijn bedenkingen over...

De tweede manier lost bovenstaand probleem om, je houdt alles lokaal bij en op het einde wordt alles definitief naar een db-record geschreven. Hier heb ik dan wel geen beveiliging over dataverlies tijdens de stappen mocht er iets foutgaan...

Hoe zouden jullie dit aanpakken? Het draait in PHP op een mysql-database.

PHP: mysql_insert_id - Manual geeft wel het ID terug van de laatste actie.

Als ge met een database gaat werken die half afgewerkte reservaties bijhoudt is dat voor uw gebruikers inderdaad het meest gebruiksvriendelijke. Maar ge zult nog steeds een cookie moeten aanmaken met de id van de reservatie om die gegevens dan terug op te halen.

Uiteindelijk kunt ge dus even goed in tussentijd alle data in een cookie bijhouden en op het einde alles in één keer wegschrijven. Het enige verschil zal zijn dat uw cookie groter in bestandsgrootte zal zijn. Zonder zult ge nooit kunnen als ge veilig wilt blijven na een browsercrash, want uw sessie is dan sowieso vernietigd.

Ik werk nie graag met cookies, ik prefereer altijd sessions tenzij het echt niet anders kan (inlog bewaren bvb). Ik kan evengoed het ID in een session bewaren. Die session wordt toch gelinkt aan die ene gebruiker via een autocookie achter de schermen.

Maar alvast bedankt voor die php-regel. Ik had geen flauw idee dat zoiets bestond!

Ja, maar een sessie is maar zolang geldig als de browser open blijft, een gecrashte browser leidt tot het verlies van uw sessie en dus ook de uw link naar de data.

Nu, als de gebruiker ingelogd moet zijn om een reservatie te kunnen plaatsen is het wel mogelijk natuurlijk.

Ik zou het meeste met Javascript doen en enkel op het einde maar php posten.

Je kan het form opsplitsen in bv. divs en dan div verbergen of tonen naar gelang de stap. Dan zit alle data wel in de html pagina dus als je dat sluit ben je alles kwijt. Ik zou ook met hash in url werken dan kan je ook de back en forward buttons gebruiken.

Je kan bijvoorbeeld achter de hash een nummer zetten en deze dan +1 of -1 doen met 2 buttons. Met een hash-changed event (ie heeft dit ingebouwd) toon je de juiste div en verberg je de rest.

Hoe ga je validatie doen? Is deze tool enkel voor je ouders of ook voor buitenstaanders? Als het enkel voor je ouders is dan kan je de meeste validatie client-side doen. jQuery.validate is daar handig voor.

Voorbeeld van jQuery.validate


En bijvoorbeeld om een veld verplicht te maken en een valid email adres hoef je enkel nog maar de juiste classes toe te voegen.


Edit:
Meestal wordt dit een wizard genoemd, kan je eens kijken wat googlen te bieden heeft. Juist zelf is gekeken en er zijn een aantal jquery wizards zo te zien.

MiniJeffrey zei:

Hi webdevelopers
* Informatie per stap wegschrijven naar DB

De eerste methode lijkt me het veiligst, als er bij de laatste stap iets gebeurt, bvb browsercrash, dan ben je al die voorgaande info niet kwijt.

Klik om te vergroten...

En hoe ga je opvangen als een gebruiker bij de laatste stap beslist om niet meer te reserveren? Als hij dus expres zijn browservenster sluit, dan zit je met nutteloze data in je database.

Alles wat in sessies komt kan idd verloren gaan wanneer men de browser sluit.

Wanneer je zou stellen dat een gebruiker moet ingelogd zijn kan je
ook een Temptabel in je database maken en je objecten of info tijdelijke serializeren naar de database.

Wanneer wordt deze info gedelete ?
- Als de gebruiker de volledige cyclus doorlopen heeft.

Wanneer blijft deze info in je temptabel staan ?
- Wanneer de gebruiker je cyclus doorbroken heeft, door bijvoorbeeld zijn browser te sluiten of een crash.

Dus wanneer een gebruiker op reserveren klikt, kan je gewoon even je temptabel raadplegen, je geserializeerde data even terug inladen in je session objecten en klaar is kees.

Dus een mooie "waterdichte" mengeling van sessions en database.

Uit je uitleg lijkt het dat dit enkel door je ouders gebruikt zal worden? Dan kan je eigenlijk gewoon na elke stap de info gewoon toevoegen aan de database en zorgen dat er een extra veld is "reservation_complete" dat op 0 blijft staan tot het einde.

Dan kan je gemakkelijk een tabel tonen met alle onafgewerkte reservaties met de opties:
-Nieuwe Reservatie starten
-Onafgewerkte reservatie vervolgen
-Onafgewerkte reservatie verwijderen

Indien ook gewone bezoekers dit moeten gebruiken ligt dat natuurlijk moeilijker en is de methode van massoo wrs meer aan te raden

Succes
(PS: Leuk om te weten dat ik binnenkort wrs niet langer de enige website-ontwikkelende treinbegeleider in belgië meer ben )

Het is inderdaad enkel voor mijn ouders te gebruiken en ik denk dat ik nu inderdaad met schrijven naar DB en een veld compleet (1 of 0) zal werken.

Javascript en Ajax ben ik nog niet genoeg meester om daar al vergaande zaken in te doen, al zou het natuurlijk wel nice zijn zoals drone zei om divs enzo te verbergen naarmate de wizard doorlopen wordt.

Gerto, yeah! Voorlopig nog geen uitslag van Frans schriftelijk. Het heeft vertraging

Eleven zei:

En hoe ga je opvangen als een gebruiker bij de laatste stap beslist om niet meer te reserveren? Als hij dus expres zijn browservenster sluit, dan zit je met nutteloze data in je database.

Klik om te vergroten...

Dat kan op zich met een cron job wel nog aangepakt worden. Maar ik denk niet dat er veel sites zijn die zo'n tussentijdse data gaan opslaan. Het is onderandere voor zo'n dingen dat sessies en cookies eigenlijk bestaan.

Nu we het over cron hebben. Ik ben ook op zoek naar een goede host om het systeem op te draaien.

Vereisten zijn:
* PHP ondersteuning
* Mogeijkheid om iets in cron te zetten zodat ik bvb dagelijks een backup van de DB kan trekken
* betrouwbaar en betaalbaar

one.com, onze huidige host, valt uit de boot omdat zij niets voorzien om db-backups te nemen.

Waarom zou je backups willen doen ? Hosts zoals one.com doen dit toch voor jou achter de schermen ?

Sent from my HTC Desire using Tapatalk

Ja, maar niet voor eigen gebruik. Die backups zijn enkel toegankelijk als er bij one.com zelf dataverlies optreedt. Als er data verloren gaat door mijn eigen fout (bvb slecht programmeren of hacking) komt one.com daar niet in tussen met hun backups.

Hoe groot is die database? Zelf backups maken is ook mogelijk

Bij MySql zit er de file mysqldump.exe. Met deze file kan je via console een back-up(dump) maken van de database. Je kan hier dan ook gewoon een batch(*.bat) file voor maken dan kan je met 1 klik je database back-uppen.

MiniJeffrey zei:

Ik werk nie graag met cookies, ik prefereer altijd sessions tenzij het echt niet anders kan (inlog bewaren bvb). Ik kan evengoed het ID in een session bewaren. Die session wordt toch gelinkt aan die ene gebruiker via een autocookie achter de schermen.

Maar alvast bedankt voor die php-regel. Ik had geen flauw idee dat zoiets bestond!

Klik om te vergroten...

Slightly off-topic:
Stuff in een session steken is handig en gemakkelijk om te developpen maar schaalt dus absoluut niet. Je kan niet van app-server switchen tijdens dezelfde sessie, je limiteert het geheugen / request, ...

Voor de meeste apps is dit geen probleem (zeker niet voor de OP) maar het is wel goed om in gedachten te houden (IMHO.)

gerto zei:

Uit je uitleg lijkt het dat dit enkel door je ouders gebruikt zal worden? Dan kan je eigenlijk gewoon na elke stap de info gewoon toevoegen aan de database en zorgen dat er een extra veld is "reservation_complete" dat op 0 blijft staan tot het einde.

Klik om te vergroten...

Of je kan gewoon de huidige stap daarin bijhouden, dan kan je bij het editen direct naar het laatste scherm terugspringen ipv de hele keten opnieuw te moeten doorlopen (wat niet wegneemt dat je best voorziet dat je voor- en achteruit in de flow kan stappen uiteraard). En uiteraard kan dat enkel als je niet ineens besluit van wat stapjes extra te voorzien (hoewel je daar ook een mouw aan kan passen door de flow apart te definiëren en de ID van de stap in de flow bij te houden, maar soit, dat gaat voor dit geval al veel te ver denk ik ).

Disa zei:

Slightly off-topic:
Stuff in een session steken is handig en gemakkelijk om te developpen maar schaalt dus absoluut niet. Je kan niet van app-server switchen tijdens dezelfde sessie, je limiteert het geheugen / request, ...

Voor de meeste apps is dit geen probleem (zeker niet voor de OP) maar het is wel goed om in gedachten te houden (IMHO.)

Klik om te vergroten...

Tegen dat je je server het moeilijk zal maken door sessions zal je al heel veel info/sessions mogen declareren hoor. Voor mijn systeempje zal dat nooit een probleem vormen. Daarnaast is een session voor belangrijke informatie veiliger dan een cookie.

MiniJeffrey zei:

Tegen dat je je server het moeilijk zal maken door sessions zal je al heel veel info/sessions mogen declareren hoor. Voor mijn systeempje zal dat nooit een probleem vormen. Daarnaast is een session voor belangrijke informatie veiliger dan een cookie.

Klik om te vergroten...

Dat denk je maar, voor jouw app is het zeker geen probleem.
Voor onze app was het een heel stuk minder.
Het was een legacy Java app geschreven in RSF/JSF/Wicket/... . We hebben er wat load tests op uitgevoerd en uitgevogeld dat we maar een 200-tal concurrent users konden draaien op 1 app server met 2GBRAM.
That's right, 200 users!

Sommige sessies hadden tot 10MB aan cache geheugen nodig. Veel ervan kwam door bad code, lack of QA en gewoon geen guidelines. Maar ook veel van de memory leaks kwamen van de frameworks die we gebruikten.
Oude versies van JSF en RSF die bijna al hun data in session caches steken bevoorbeeld.

jQuery!