Ik heb een website waarin per pagina ongeveer vijf instellingen opgeslagen kunnen worden. Dit gebeurd momenteel doormiddel van cookies, waarbij ik op problemen stuit. Na een aantal pagina's bezocht te hebben wordt namelijk het cookie met de session ID gewist (waardoor ik uitgelogd raak), omdat ik meer dan een stuk of 40 cookies probeer aan te maken (het limiet per domein denk ik). Mijn vraag is dus of er een andere manier waarop ik data kan bewaren m.b.v. Javascript? Ik zit overigens qua grootte ver onder de 4Kb.
bewaar meerdere gegevens in 1 cookie (bv comma-separated).
Dus bv:
daarna gewoon parsen (bv in PHP met een preg, split...)
Dus bv:
code:
1
| "cookie1" => 1,A,22,BB,9,3 |
daarna gewoon parsen (bv in PHP met een preg, split...)
code:
1
2
3
| var 1 = 1 var 2 = A ... |
[ Voor 62% gewijzigd door webinn op 05-10-2008 17:40 ]
Waarom sla je niet meerdere gegevens op in 1 cookie? Dan kom je niet aan die limiet qua hoeveelheid.
Sole survivor of the Chicxulub asteroid impact.
Ik zat daar ook al aan te denken, maar ik vroeg mij af of er misschien een makkelijkere manier was. Weet iemand overigens hoe dat met die limieten zit? Ik zie bij mij zo'n 40 a 50 cookies staan voordat het fout gaat, maar ik dacht (na even Googlen) dat deze limiet op 20 lag. Is dat per browser verschillend? En wat is dan (als de cookies uberhaupt aanstaan) het laagste aantal (oftewel de bottleneck)?
Meerdere variabelen in 1 cookie lijkt me echt wel de beste oplossing, anders ga je zeker tegen problemen aanlopen met verschillende browsers (ik spreek uit ervaringZeroSixZero schreef op zondag 05 oktober 2008 @ 17:40:
Ik zat daar ook al aan te denken, maar ik vroeg mij af of er misschien een makkelijkere manier was. Weet iemand overigens hoe dat met die limieten zit? Ik zie bij mij zo'n 40 a 50 cookies staan voordat het fout gaat, maar ik dacht (na even Googlen) dat deze limiet op 20 lag. Is dat per browser verschillend? En wat is dan (als de cookies uberhaupt aanstaan) het laagste aantal (oftewel de bottleneck)?
Sorry, maar ik ben blij dat browsers dit soort limieten inbouwen, om te voorkomen dat websitebouwers maar als een gek cookies aan gaan lopen maken. 50 cookies is echt te zot gewoon.ZeroSixZero schreef op zondag 05 oktober 2008 @ 17:40:
Ik zat daar ook al aan te denken, maar ik vroeg mij af of er misschien een makkelijkere manier was. Weet iemand overigens hoe dat met die limieten zit? Ik zie bij mij zo'n 40 a 50 cookies staan voordat het fout gaat, maar ik dacht (na even Googlen) dat deze limiet op 20 lag. Is dat per browser verschillend? En wat is dan (als de cookies uberhaupt aanstaan) het laagste aantal (oftewel de bottleneck)?
Ik snap ook werkelijkwaar niet waar je zoveel cookies voor nodig hebt. Je kunt instellingen opslaan in 1 cookie, daar heb je er toch geen 50 voor nodig?
Verwijderd
Volgens mij is dit eerder bij elkaar 'geprakt' dan gekozen voor een logische oplossing.
Alles in 1 of 2 cookies stoppen is de oplossing
Alles in 1 of 2 cookies stoppen is de oplossing
Ik wilde omzeilen dat ik elke keer moet imploden / exploden voor het maken / lezen van cookiesBosmonster schreef op zondag 05 oktober 2008 @ 17:44:
[...]
Sorry, maar ik ben blij dat browsers dit soort limieten inbouwen, om te voorkomen dat websitebouwers maar als een gek cookies aan gaan lopen maken. 50 cookies is echt te zot gewoon.
Ik snap ook werkelijkwaar niet waar je zoveel cookies voor nodig hebt. Je kunt instellingen opslaan in 1 cookie, daar heb je er toch geen 50 voor nodig?
Sla je settings op in een array of een object, en serialize die?
Code (untested):
Op een andere pagina lees je het dan zo uit:
Code (untested):
PHP:
1
2
3
4
5
6
7
8
9
10
11
12
| <?php $settings = array( "name" => "Alex", "leeftijd" => "20", "woonplaats" => "Breda", "huisdieren" => "Vissen" ); $settingsSerialized = serialize($settings); setcookie("settings", urlencode($settingsSerialized), time() + 365 * 24 * 60 * 60 * 1000); ?> |
Op een andere pagina lees je het dan zo uit:
PHP:
1
2
3
4
5
| <?php $settings = unserialize(urldecode($_COOKIE["settings"])); echo $settings["naam"]; ?> |
We are shaping the future
Serializen ken ik wel met PHP, maar met Javascript ben ik daar niet bekend mee. Het gaat om pagina's die AJAX gebruiken, maar ik gebruik juist cookies via Javascript zodat ik niet een extra request moet maken voor de instellingen.
Gebruik dan JSON, werkt vanuit PHP, en vanuit Javascript (hence JavaScript Object Notation).ZeroSixZero schreef op zondag 05 oktober 2008 @ 17:57:
Serializen ken ik wel met PHP, maar met Javascript ben ik daar niet bekend mee. Het gaat om pagina's die AJAX gebruiken, maar ik gebruik juist cookies via Javascript zodat ik niet een extra request moet maken voor de instellingen.
[ Voor 9% gewijzigd door Snake op 05-10-2008 18:10 ]
Going for adventure, lots of sun and a convertible! | GMT-8
Vergeet niet dat cookies ook elke keer mee gestuurd worden. Die extra requestjes zouden dus wel eens minder zwaar kunnen zijn als elke keer die extra cookies. Het is natuurlijk wel wat meer werk.
Gewoon de gegevens comma-seperated opslaan is inderdaad de oplossing. Ik zou zo'n functie gebruiken om het wat flexibeler te maken. (kijk wel uit met comma's in de waarden, eventueel kun je nog wat encapsulation toevoegen als dat inderdaad kan)
Gewoon de gegevens comma-seperated opslaan is inderdaad de oplossing. Ik zou zo'n functie gebruiken om het wat flexibeler te maken. (kijk wel uit met comma's in de waarden, eventueel kun je nog wat encapsulation toevoegen als dat inderdaad kan)
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| // shamelessly gestolen van quiksmode.org
// function to read a cookievar nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0;i < ca.length;i++) {
var c = ca[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
}
return null;
}
// Example of cookie config: config1=waarde1,config2=waarde2
// Function to read configuration
function readConfig(config) {
// if no configuration is passed, read it from the default cookie
if(config == undefined){
var config = readCookie('config');
}
var ConfigVals = new Array();
var splitConfig = config.split(",");
for(i=0;i<splitConfig.length;i++){
var configVal = splitConfig[i].split("=");
ConfigVals[configVal[0]] = configVal[1];
}
return ConfigVals;
} |
Welke instellingen sla je in cookies op als ik vragen mag?ZeroSixZero schreef op zondag 05 oktober 2008 @ 17:36:
Ik heb een website waarin per pagina ongeveer vijf instellingen opgeslagen kunnen worden.
Speel ook Balls Connect en Repeat
Dat zal niks veranderen aan het feit dat je nog steeds een extra request moet doen om configuratie-instellingen op te slaan.Snake schreef op zondag 05 oktober 2008 @ 18:10:
[...]
Gebruik dan JSON, werkt vanuit PHP, en vanuit Javascript (hence JavaScript Object Notation).
Ik heb een lijst met verschillende kolommen/rijen die gesorteerd kan worden. Omdat een gebruiker niet elke keer de sortering, zoekterm etc. in wil vullen worden deze bewaard in een cookie. Bij aanroep van de pagina wordt de omgeving weer hersteld naar de waarden van het vorige bezoek. Na het herstellen van de interface wordt alle data van de lijst geladen via AJAX. Wijzigingen in de data gaan ook via AJAX.Onbekend schreef op zondag 05 oktober 2008 @ 18:14:
[...]
Welke instellingen sla je in cookies op als ik vragen mag?
Het opslaan in één cookie is inmiddels een feit, nu het uitlezen nog (geef me een kwartiertje
Als je al met AJAX werkt neem ik aan dat je een fatsoenlijk framework gebruikt. Die hebben over het algemeen ook cookie-management ingebouwd.
Wat mij betreft is de gekozen richting niet optimaal. Instellingen in 1 of 40 cookies is niet zo relevant.
Ik zou alle instellingen server side opslaan. Dit is relatief makkelijk gedaan en heeft een aantal voordelen:
- session cookie is genoeg
- instellingen gaan niet elke keer de lijn over
- geen beperkingen op aantal instellingen
- als alle cookies verwijderd worden in de browser, dan blijven de instellingen bewaard
Ik zou alle instellingen server side opslaan. Dit is relatief makkelijk gedaan en heeft een aantal voordelen:
- session cookie is genoeg
- instellingen gaan niet elke keer de lijn over
- geen beperkingen op aantal instellingen
- als alle cookies verwijderd worden in de browser, dan blijven de instellingen bewaard
Klik hier om mij een DM te sturen • 3245 WP op ZW
Uiteraard alleen als je de instellingen koppelt aan de gebruikersnaam, aangezien het sessie-cookie ook verdwenen zal zijn.- als alle cookies verwijderd worden in de browser, dan blijven de instellingen bewaard
Het is de vraag of zoiets nodig is bij iets als het sorteren van een tabel.
Uiteraard is een ingelogde sessie het mooistdtech schreef op zondag 05 oktober 2008 @ 22:41:
[...]
Uiteraard alleen als je de instellingen koppelt aan de gebruikersnaam, aangezien het sessie-cookie ook verdwenen zal zijn.
Het is de vraag of zoiets nodig is bij iets als het sorteren van een tabel.
Wellicht is het niet perse nodig bij deze functionaliteit, maar als we het al over 40 cookies hebben dan zijn er wel iets meer dan 5 instellingen. Ik benader het dan toch nog van een andere invalshoek. Stel dat de applicatie in kwestie nog flink gaat groeien en dat er nog veel meer views komen die instellingen willen opslaan, dan bestaat de kans dat de 1-cookie strategie tegen de limieten van het cookie aanlopen. Wat gaat er dan gebeuren? Een 2e cookie aanmaken en daar verder in verzamelen? En een 3e en 4e? Vanuit dat oogpunt lijkt me het opslaan van de settings op de server wel een best practice. En het is niet zo dat dit waanzinnig moeilijk is.
Klik hier om mij een DM te sturen • 3245 WP op ZW
Mooiste is om (persoonlijke) voorkeuren gewoon in een DB op te slaan. Anders moet je met elke sessie je instellingen opnieuw doen...
@GTje: Ik doelde op het feit dat iemand bij naam is ingelogd, zodat je zijn of haar settings persoonlijk kan opslaan op de server over sessies heen. Dat ik van mening ben dat deze gegevens uberhaubt opgeslagen moeten worden op de server had ik al duidelijk gemaakt in mijn eerste reactie.
Klik hier om mij een DM te sturen • 3245 WP op ZW
Gewoon sessies gebruiken lijkt mij ook de mooiste oplossing.
Als je sortering wil toepassen lijkt me dat toch netter om op PHP niveau te doen dan op JavaScript niveau, dus dan kan je net zo goed de sessie gebruiken ipv cookies..
Als je sortering wil toepassen lijkt me dat toch netter om op PHP niveau te doen dan op JavaScript niveau, dus dan kan je net zo goed de sessie gebruiken ipv cookies..
Het gaat om vijf instellingen (en een lijst identifier) die op elke pagina terugkomen, te weten:
identifier (String)
startpagina (integer)
limit (integer)
zoekterm (String)
sorteerkolom (String)
sorteervolgorde (boolean)
In een cookie wordt dat dus als voorbeeld (voor een enkel item):
toplist, 0, 25, zoek, rank, 0
Aangezien er op elke pagina een andere lijst staat, moeten de instellingen dus per pagina (of anders gezegd: per lijst) opgeslagen worden. Momenteel sla ik dus deze instellingen op in een cookie en stuur ik deze bij de AJAX request mee. PHP genereert dan een geordende lijst en stuurt deze terug. Jullie suggereren dus dat ik het beste de instellingen Server Side op kan slaan en dan bij de requests de wijzigingen in instellingen doorstuur. Grootste voordeel hiervan zou zijn dat ik niet afhankelijk ben van cookies (alhoewel, de sessie variabele wordt daar ook opgeslagen dus ze moeten sowieso aanstaan) en de bijbehorende limiet van 4Kb (dat is volgens mij behoorlijk wat voor de simpele instellingen die ik hierboven beschrijf. Ik gebruik nu een stuk of 12 lijsten). Nu vraag ik mij af of het belasten van de databas beter is dan het belasten van de computer van de client (aanmaken cookies). Ik denk dat ik het systeem (het werkt nu geheel dankzij jullie goede feedback) momenteel met cookies zal laten werken. Indien dit problemen oplevert kan ik later nog overwegen om het geheel in een database te gooien.
identifier (String)
startpagina (integer)
limit (integer)
zoekterm (String)
sorteerkolom (String)
sorteervolgorde (boolean)
In een cookie wordt dat dus als voorbeeld (voor een enkel item):
toplist, 0, 25, zoek, rank, 0
Aangezien er op elke pagina een andere lijst staat, moeten de instellingen dus per pagina (of anders gezegd: per lijst) opgeslagen worden. Momenteel sla ik dus deze instellingen op in een cookie en stuur ik deze bij de AJAX request mee. PHP genereert dan een geordende lijst en stuurt deze terug. Jullie suggereren dus dat ik het beste de instellingen Server Side op kan slaan en dan bij de requests de wijzigingen in instellingen doorstuur. Grootste voordeel hiervan zou zijn dat ik niet afhankelijk ben van cookies (alhoewel, de sessie variabele wordt daar ook opgeslagen dus ze moeten sowieso aanstaan) en de bijbehorende limiet van 4Kb (dat is volgens mij behoorlijk wat voor de simpele instellingen die ik hierboven beschrijf. Ik gebruik nu een stuk of 12 lijsten). Nu vraag ik mij af of het belasten van de databas beter is dan het belasten van de computer van de client (aanmaken cookies). Ik denk dat ik het systeem (het werkt nu geheel dankzij jullie goede feedback) momenteel met cookies zal laten werken. Indien dit problemen oplevert kan ik later nog overwegen om het geheel in een database te gooien.
Ik raad je aan om je eens te verdiepen in de werking van een sessie en het http protocol ansich.
Ten eerste worden sessie variabelen niet op de client opgeslagen. De sessie variabelen worden op de server opgeslagen en bij de client wordt enkel een token (de sessionId) neergezet (in een cookie, of meegegeven aan de url wanneer cookies uit staan).
Gegevens die in een cookie opgeslagen worden worden elk request weer opnieuw meegestuurd! Door de cookies te gebruiken belast je niet alleen de client (marginaal), maar ook het request verkeer.
Waarom overweeg je trouwens maar 2 alternatieven (database vs cookies)? De meest voor de hand liggende keuze lijkt mij toch echt het opslaan in de sessie.
Ten eerste worden sessie variabelen niet op de client opgeslagen. De sessie variabelen worden op de server opgeslagen en bij de client wordt enkel een token (de sessionId) neergezet (in een cookie, of meegegeven aan de url wanneer cookies uit staan).
Gegevens die in een cookie opgeslagen worden worden elk request weer opnieuw meegestuurd! Door de cookies te gebruiken belast je niet alleen de client (marginaal), maar ook het request verkeer.
Waarom overweeg je trouwens maar 2 alternatieven (database vs cookies)? De meest voor de hand liggende keuze lijkt mij toch echt het opslaan in de sessie.
Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'
Voor dit zou ik inderdaad sessies gebruiken. Easy te gebruiken, is precies wat je nodig hebt, en belast het verkeer minder zoals Janoz al zei.
We are shaping the future
Pagina: 1