Web/Local storage feature HTML5

[dj_vibri]

Momenteel ben ik me aan het verdiepen, onderzoeken voor project, in heel het HTML5 gebeuren.
De applicatie die gebouwd dient te worden zal eenvoudig weg dienen voor het maken van reservatie's voor twee vakantiewoningen.

Hiervoor gebruik ik een SQL DB voor user gegevens in te bewaren, reservatie data e.d.

De site zal meertalig moeten zijn en voor html5 zou ik gebruik gemaakt hebben van ofwel cookies ofwel Browser Default Language.

Nu heb ik gemerkt dat het een, redelijk hot-topic, feature is betreffende de "Web Storage" (of Local storage?) binnen HTML5 waarbij je DB content kunt opslaan op de gebruiker zijn pc zelf, waardoor er minder http requests dienen te gebeuren.

Nu vroeg ik mij af of het in mijn geval handig is om dit te gebruiken voor enerzijds het bijhouden van de gekozen taal (of toch gaan voor de browser default language?) alsook het overpompen van "bestaande reservaties". Waarom denk ik aan dit laatste, wanneer gebruiker dan een periode invoert om te controleren of er iets beschikbaar is kan de data lokaal opgehaald worden.

Nu lijkt het mij serieus overkill te zijn om een lokale DB te creëren hiervoor, tenzei er mensen hier anders over denken hoor ik het graag!

En langs de andere kant vraag ik me af welke website echt off-line bereikbaar moet zijn (caching), op het moment dat je de site bezoekt on-line heb je de site gezien, dan ga je 's avonds toch niet off-line naar de site zien als je weet dat er content kan veranderd zijn? (sowieso zie ik wat betreft caching geen nuttige mogelijkheid voor mijn applicatie, maar ben benieuwd wat anderen er van denken).

[Verwijderd]

Het idee achter een database is om op een centrale plek een consistente verzameling gegevens te bewaren. Zodra je dit soort gegevens lokaal gaat opslaan bij de gebruiker, ben je de totale controle natuurlijk kwijt. Ik denk niet dat dat de bedoeling is achter de 'local storage' van HTML5. Wellicht zouden user settings, of data die hij sowieso altijd mag wijzigen en die niet kritisch zijn voor de functionaliteit van jouw applicatie eventueel lokaal opgeslagen kunnen worden. Besef je echter wel dat lokaal in dit geval betekent dat het systeem specifiek is, bezoekt hij je applicatie met een ander device, dan zijn die gegevens niet beschikbaar (je zal dus altijd een remote kopie moeten bewaren).

Bovendien twijfel ik een beetje aan het feit of je in dit soort applicatie uberhaubt winst haalt door gegevens lokaal op te slaan, jouw database server zal ongetwijfeld veel beter ingericht zijn voor het opslaan en verwerken van gegevens. Ook zijn tegenwoordig de http requests marginaal ten opzichte van de beschikbare bandbreedte (los van plaatjes dan, maar die worden al jaren gecached door de browser).

[ Voor 8% gewijzigd door Verwijderd op 08-12-2010 12:51 ]

[dj_vibri]

sowieso zal er een DB komen te staan op server niveau met alle gegevens die nodig zijn.
Ook wil ik ervoor zorgen dat gebruikers eerst moeten registreren alvorens een boeking te kunnen doen (kwestie van "fake" boekingen zoals we de laatste tijd hebben) te voorkomen, met naam/adres/enz....

extra functie zou dan ook kunnen zijn dat we een "boekings historiek" voor de gebruikers kunnen bijhouden, misschien niet nuttig maar toch een extra iets voor de moeite die ze doen om te registreren

Misschien dat ik deze content wel lokaal kan opslaan en wanneer ze opnieuw inloggen, de data op server niveau vergeleken wordt met lokale db en indien dit verschilt de lokale content updaten? en anders gebruik maken van lokale data?

Wel heb ik daarnet ergens gelezen, kan resource niet direct terug vinden, dat je dmv lokale db geen loop statements kan uitvoeren wanneer er meerdere records zijn? klopt dit?

zo ja, dan ga ik gewoon geen gebruik maken van lokale DB voor boekingshistoriek omdat ik dit dan toch niet kan gebruiken als ze 2x al een boeking hebben gedaan...

[Raymond P]

Wel heb ik daarnet ergens gelezen, kan resource niet direct terug vinden, dat je dmv lokale db geen loop statements kan uitvoeren wanneer er meerdere records zijn? klopt dit?

Dat ligt aan je structuur van opslaan.
Voor zover ik weet kan je geen objecten opslaan naar localstorage.
In het project waar ik mee bezig ben probeer ik dat op te vangen door JSON te gebruiken.
Zo kan je je hele object in 1 key zetten en de structuur behouden na het wegschrijven en uitlezen, en dus eventueel loopen.

[moozzuzz]

Zoals al hierboven gezegd zou ik ook suggereren om evt. enkel usersettings in een cookie te gooien maar voor de rest (en zeker in geval van een reservatie-systeem dat toch steeds realtime moet zijn) zie ik weinig excuses om met de localDB te rotzooien (los vh feit dat dit nog niet in alle browsers zal werken).

[samo]

Inderdaad is voor een enkele setting de database zware overkill en ook nog een beetje te buggy en te slecht ondersteund (alleen Webkit).
Voor een boekingsysteem kan je best alle informatie lokaal overzetten waardoor het opzoeken van vrije slots enorm snel gaat. Om de boeking weg te schrijven zou ik dat toch serverside nog eens checken, voor het geval er twee gebruikers op hetzelfde moment werken.
Ik heb laatst bij wijze van proof-of-concept onze productendatabase van 19.000 producten eens ingelezen voor een realtime auto-aanvullen module. Werkte prima in chrome. Alleen zorgen dat je altijd de juiste gegevens hebt is nogal lastig.

[Raymond P]

samo schreef op maandag 13 december 2010 @ 20:37:
Inderdaad is voor een enkele setting de database zware overkill en ook nog een beetje te buggy en te slecht ondersteund (alleen Webkit).

Uit nieuwsgierigheid, wat voor bugs liep je tegenaan?
Overigens werkt het hier in Safari, Chrome, Firefox, Opera en (iig) IE9.

[Koetjeboe]

Wij gebruiken hier localStorage o.a. in de backend om ervoor te zorgen dat gegevens uit bijv textarea's niet verloren gaan als de gebruiker 'perongeluk' de browser afsluit of naar een andere pagina gaat. Werkt op zich prima (ook crossbrowser. Er is ook goed op te checken of het beschikbaar is) alleen merkten we wel wat bezorgdheid van gebruikers als ze de melding krijgen 'Deze website probeert gegevens lokaal op te slaan' (o.i.d.) Zorg dus dat het duidelijk is wat er gebeurd en waarom en dat ze hiervoor eerst toestemming moeten geven.

[samo]

Raymond P schreef op dinsdag 14 december 2010 @ 11:45:
[...]
Uit nieuwsgierigheid, wat voor bugs liep je tegenaan?
Overigens werkt het hier in Safari, Chrome, Firefox, Opera en (iig) IE9. Het versioning van databases werkt nog niet goed.

Ik heb dan getest met WebSQL welke alleen goed werkt in webkit, en liep tegen ontbreken van foutafhandeling.